On 30 September 2016 at 16:41, Felix Janda <felix.ja...@posteo.de> wrote:
> 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.
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...
> ---
> linux-user/signal.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index c750053..c89f83d 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -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];
>
> --
> 2.7.3
>
thanks
-- PMM
