Peter Maydell wrote: > 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.
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