Re: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[Felix Janda <felix.janda@posteo.de>]

Peter Maydell wrote:
> On 30 September 2016 at 16:41, Felix Janda <felix.janda@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.

Thanks for explaining this.

> 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.

> 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