This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [linux] Always ignore restart/cancellation signals
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 <drow@false.org>
> >
> > 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 <drow@false.org>
> > > >
> > > > 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