From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11704 invoked by alias); 9 Dec 2005 18:58:14 -0000 Received: (qmail 11697 invoked by uid 22791); 9 Dec 2005 18:58:14 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 09 Dec 2005 18:58:12 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EknRa-0004si-4T for gdb-patches@sourceware.org; Fri, 09 Dec 2005 13:58:10 -0500 Date: Sat, 10 Dec 2005 01:29:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: [linux] Always ignore restart/cancellation signals Message-ID: <20051209185810.GA18701@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00179.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery, LLC