From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21396 invoked by alias); 9 Dec 2005 20:49:43 -0000 Received: (qmail 21386 invoked by uid 22791); 9 Dec 2005 20:49:42 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Dec 2005 20:49:41 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jB9Kn6mb018775; Fri, 9 Dec 2005 21:49:06 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jB9Kn6uP026250; Fri, 9 Dec 2005 21:49:06 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jB9Kn59V026226; Fri, 9 Dec 2005 21:49:05 +0100 (CET) Date: Sat, 10 Dec 2005 01:49:00 -0000 Message-Id: <200512092049.jB9Kn59V026226@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20051209185810.GA18701@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 9 Dec 2005 13:58:10 -0500) Subject: Re: [linux] Always ignore restart/cancellation signals References: <20051208142420.GA21882@nevyn.them.org> <200512081950.jB8Jo9im029464@elgar.sibelius.xs4all.nl> <20051208133824.24b4c680@ironwood.lan> <20051208204301.GA29490@nevyn.them.org> <20051209143451.GA11917@nevyn.them.org> <20051209144651.GA12425@nevyn.them.org> <20051209185810.GA18701@nevyn.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00182.txt.bz2 > Date: Fri, 9 Dec 2005 13:58:10 -0500 > From: Daniel Jacobowitz > > On Fri, Dec 09, 2005 at 08:51:23PM +0200, Eli Zaretskii wrote: > > > Date: Fri, 9 Dec 2005 09:46:51 -0500 > > > From: Daniel Jacobowitz > > > > > > On Fri, Dec 09, 2005 at 04:44:16PM +0200, Eli Zaretskii wrote: > > > > > Date: Fri, 9 Dec 2005 09:34:52 -0500 > > > > > From: Daniel Jacobowitz > > > > > > > > > > The problem is that an application may want to register handlers for "a > > > > > few" realtime signals. It seems common to count up from SIGRTMIN, so > > > > > SIGRTMIN is made a runtime constant that skips those signals belonging > > > > > to the implementation. > > > > > > > > Does this mean that ``constants aren't'', like the old joke says? > > > > > > Precisely! Directly above the bit Kevin quoted: > > > > > > #define SIGRTMIN (__libc_current_sigrtmin ()) > > > #define SIGRTMAX (__libc_current_sigrtmax ()) > > > > Then we should probably use these instead. > > No, we shouldn't. Let me try the explanation over from the top. > > The thread library reserves some realtime signals to itself. These are > specifically those between __SIGRTMIN (a constant) and SIGRTMIN (a > function call). A well-behaved application should not manually > generate those signals nor attempt to handle them. > > But GDB isn't trying to use realtime signals. It's trying to find the > signals used by the inferior's threading implementation, so that it can > transparently ignore them, instead of stopping the application by > default every time that a thread is cancelled (or, for LinuxThreads, > every time a thread blocked on a mutex is woken!). > > If the thread library is kind enough to tell us which signals it is > using, then we use those numbers. If it isn't, we must guess. The > only correct guess is __SIGRTMIN (32 on all Linux systems, and this is > Linux-specific code...) and __SIGRTMIN+1. SIGRTMIN is generally 34 or > 35, and would be the right choice for GDB to use in sending its own > signals to itself. Ah yes, it all comes back to me. Believe SIGRTMIN will be 32, unless you link your stuff with libpthreads, since that consumes two signals for internal use, and therefore SIGRTMIN will be 34. Are the signal numbers hardcoded in libpthread (in particular the NPTL one) or does it depend on whether there are other consumers of real-time signals? Mark