linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined
RFC PATCH 1/1 linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined
This fixes a compilation error with the musl c library.
---
I don't really understand the purpose of the hack, which was introduced in
http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
but musl does not have a separate thread library (it is included in libc.so), so I doubt that the hack is applies to it.
--- linux-user/signal.c | 2 ++ 1 file changed, 2 insertions(+)
linux-user/signal.c +2 -0
@@ -73,12 +73,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = { [SIGPWR] = TARGET_SIGPWR, [SIGSYS ] =TARGET_SIGSYS ,/* next signals stay the same */ +#ifdef __SIGRTMIN/* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with host libpthread signals. This assumes no one actually uses SIGRTMAX :-/ To fix this properly we need to do manual signal delivery multiplexed over a single host signal. */ [__SIGRTMIN] = __SIGRTMAX, [__SIGRTMAX] = __SIGRTMIN, +#endif };static uint8_t target_to_host_signal_table[_NSIG];
Signature · 1 line
2.7.3
Your series seems to have some coding style problems. See output below for more information:
Hi,
Your series seems to have some coding style problems. See output below for more information:
Type: series
Message-id: 20160930234101.GD5887@nyan
Subject: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True
commits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do
echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/20160930234021.GC5887@nyan -> patchew/20160930234021.GC5887@nyan
* [new tag] patchew/20160930234101.GD5887@nyan -> patchew/20160930234101.GD5887@nyan
Switched to a new branch 'test'
5a29f11 linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined
=== OUTPUT BEGIN ===
Checking PATCH 1/1: linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined...
WARNING: architecture specific defines should be avoided
#18: FILE: linux-user/signal.c:76:
+#ifdef __SIGRTMIN
ERROR: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 14 lines checked
Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to [email protected]
Quoted 9 lines · Felix Janda
This fixes a compilation error with the musl c library.
---
I don't really understand the purpose of the hack, which was introduced inhttp://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
but musl does not have a separate thread library (it is included in libc.so), so I doubt that the hack is applies to it.
The reason for the hack is that glibc uses SIGRTMAX (ie signal 63) for its own internal purposes (it uses it for between-thread communication to implement the posix threading APIs). If we didn't reverse SIGRTMIN and SIGRTMAX then both the glibc in the host process and the glibc in the guest process would try to use the same signal and the guest's threading APIs would break.
I'm pretty sure musl is going to need to use a signal to implement threads too, so I expect this hack will be needed there too, not just on glibc.
It would be better to figure out how to identify the range of RT signals on musl...
Quoted 24 lines
--- linux-user/signal.c | 2 ++ 1 file changed, 2 insertions(+)linux-user/signal.c +2
-1@@ -73,12 +73,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = { [SIGPWR] = TARGET_SIGPWR, [SIGSYS ] =TARGET_SIGSYS ,/* next signals stay the same */ +#ifdef __SIGRTMIN/* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with host libpthread signals. This assumes no one actually uses SIGRTMAX :-/ To fix this properly we need to do manual signal delivery multiplexed over a single host signal. */ [__SIGRTMIN] = __SIGRTMAX, [__SIGRTMAX] = __SIGRTMIN, +#endif };static uint8_t target_to_host_signal_table[_NSIG]; --
Quoted 2 lines
2.7.3
thanks
-- PMM
Quoted 11 lines · Peter Maydell
Quoted 9 lines · Felix Janda
This fixes a compilation error with the musl c library.
---
I don't really understand the purpose of the hack, which was introduced inhttp://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
but musl does not have a separate thread library (it is included in libc.so), so I doubt that the hack is applies to it.
Quoted 7 lines
The reason for the hack is that glibc uses SIGRTMAX (ie signal 63) for its own internal purposes (it uses it for between-thread communication to implement the posix threading APIs). If we didn't reverse SIGRTMIN and SIGRTMAX then both the glibc in the host process and the glibc in the guest process would try to use the same signal and the guest's threading APIs would break.
Thanks for explaining this.
Quoted 3 lines
I'm pretty sure musl is going to need to use a signal to implement threads too, so I expect this hack will be needed there too, not just on glibc.
musl uses signal 34 (internally called SIGSYNCCALL) to implement threads.
Quoted 2 lines
It would be better to figure out how to identify the range of RT signals on musl...
musl has SIGRTMIN and SIGRTMAX, but these resolve to functions __libc_current_sigrtmin() and __libc_current_sigrtmax(). The first always returns 35, the second _NSIG-1.
But how do these matter? Isn't it only important that signal 34 gets remapped?
Felix