From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqB5a-0000NY-VD for qemu-devel@nongnu.org; Fri, 30 Sep 2016 23:35:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqB5W-0007ia-1C for qemu-devel@nongnu.org; Fri, 30 Sep 2016 23:35:50 -0400 Received: from mout02.posteo.de ([185.67.36.66]:52263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqB5V-0007iS-Qx for qemu-devel@nongnu.org; Fri, 30 Sep 2016 23:35:45 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 4893620B85 for ; Sat, 1 Oct 2016 05:35:42 +0200 (CEST) Date: Fri, 30 Sep 2016 23:33:49 -0400 From: Felix Janda Message-ID: <20161001033349.GB23216@nyan> References: <20160930234101.GD5887@nyan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Riku Voipio Peter Maydell wrote: > On 30 September 2016 at 16:41, Felix Janda 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