[linux] Always ignore restart/cancellation signals

[linux] Always ignore restart/cancellation signals

[Daniel Jacobowitz]

The comment is fairly self-explanatory.  I guess I've always debugged
failing cancellation tests with gdbserver, which hardwires these values
already...

Any objections?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-12-07  Daniel Jacobowitz  <dan@codesourcery.com>

	* linux-nat.c (lin_thread_get_thread_signals): Default to __SIGRTMIN
	and __SIGRTMIN + 1.

Index: gdb-6.4/gdb/linux-nat.c
===================================================================
--- gdb-6.4.orig/gdb/linux-nat.c	2005-11-03 14:51:40.000000000 -0500
+++ gdb-6.4/gdb/linux-nat.c	2005-12-07 21:44:12.000000000 -0500
@@ -3284,12 +3284,18 @@ lin_thread_get_thread_signals (sigset_t 
   sigemptyset (set);
 
   restart = get_signo ("__pthread_sig_restart");
+  cancel = get_signo ("__pthread_sig_cancel");
+
+  /* LinuxThreads normally uses the first two RT signals, but in some legacy
+     cases may use SIGUSR1/SIGUSR2.  NPTL always uses RT signals, but does
+     not provide any way for the debugger to query the signal numbers -
+     fortunately they don't change!  */
+
   if (restart == 0)
-    return;
+    restart = __SIGRTMIN;
 
-  cancel = get_signo ("__pthread_sig_cancel");
   if (cancel == 0)
-    return;
+    cancel = __SIGRTMIN + 1;
 
   sigaddset (set, restart);
   sigaddset (set, cancel);

Re: [linux] Always ignore restart/cancellation signals

[Mark Kettenis]

> Date: Thu, 8 Dec 2005 09:24:20 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> The comment is fairly self-explanatory.  I guess I've always debugged
> failing cancellation tests with gdbserver, which hardwires these values
> already...
> 
> Any objections?

Hmm, I thought symbols starting with __ were "reserved by the
implemntation" and should not be used by user space programs.

Re: [linux] Always ignore restart/cancellation signals

[Kevin Buettner]

On Thu, 8 Dec 2005 20:50:09 +0100 (CET)
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > Date: Thu, 8 Dec 2005 09:24:20 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > The comment is fairly self-explanatory.  I guess I've always debugged
> > failing cancellation tests with gdbserver, which hardwires these values
> > already...
> > 
> > Any objections?
> 
> Hmm, I thought symbols starting with __ were "reserved by the
> implemntation" and should not be used by user space programs.

For the symbols in question, the header file, <bits/signum.h>, says:

    /* These are the hard limits of the kernel.  These values should not be
       used directly at user level.  */
    #define __SIGRTMIN	32
    #define __SIGRTMAX	(_NSIG - 1)

So the comment supports your claim.

The only alternative that I can think of is to hardcode the constant
(32, in this case) into the GDB sources.  Of these two approaches, I'd
prefer to use __ symbol from the system headers.  I do think that we
ought to check for its existence first though.

Kevin

Re: [linux] Always ignore restart/cancellation signals

[Daniel Jacobowitz]

On Thu, Dec 08, 2005 at 01:38:24PM -0700, Kevin Buettner wrote:
> > Hmm, I thought symbols starting with __ were "reserved by the
> > implemntation" and should not be used by user space programs.

We're a program tightly tied to the implementation, and they're symbols
provided by the implementation.  gdbserver already uses them; rda was
recently changed to use them; gdb/signals/signals.c already uses them.
> 
> For the symbols in question, the header file, <bits/signum.h>, says:
> 
>     /* These are the hard limits of the kernel.  These values should not be
>        used directly at user level.  */
>     #define __SIGRTMIN	32
>     #define __SIGRTMAX	(_NSIG - 1)
> 
> So the comment supports your claim.
> 
> The only alternative that I can think of is to hardcode the constant
> (32, in this case) into the GDB sources.  Of these two approaches, I'd
> prefer to use __ symbol from the system headers.  I do think that we
> ought to check for its existence first though.

I'll do it if you like.  They will exist in all LinuxThreads and NPTL
headers, to the best of my knowledge, and if you don't have either of
those than linux-thread-db.c won't do you any good anyway...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [linux] Always ignore restart/cancellation signals

[Kevin Buettner]

On Thu, 8 Dec 2005 15:43:01 -0500
Daniel Jacobowitz <drow@false.org> wrote:

> > [...] I do think that we
> > ought to check for its existence first though.
> 
> I'll do it if you like.  They will exist in all LinuxThreads and NPTL
> headers, [...]

If you're confident that this is the case, then I withdraw my request
to first check for the existence of __SIGRTMIN.

Kevin

Re: [linux] Always ignore restart/cancellation signals

[Eli Zaretskii]

> Date: Thu, 8 Dec 2005 15:43:01 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> On Thu, Dec 08, 2005 at 01:38:24PM -0700, Kevin Buettner wrote:
> > > Hmm, I thought symbols starting with __ were "reserved by the
> > > implemntation" and should not be used by user space programs.
> 
> We're a program tightly tied to the implementation, and they're symbols
> provided by the implementation.  gdbserver already uses them; rda was
> recently changed to use them; gdb/signals/signals.c already uses them.
> > 
> > For the symbols in question, the header file, <bits/signum.h>, says:
> > 
> >     /* These are the hard limits of the kernel.  These values should not be
> >        used directly at user level.  */
> >     #define __SIGRTMIN	32
> >     #define __SIGRTMAX	(_NSIG - 1)
> > 
> > So the comment supports your claim.
> > 
> > The only alternative that I can think of is to hardcode the constant
> > (32, in this case) into the GDB sources.  Of these two approaches, I'd
> > prefer to use __ symbol from the system headers.  I do think that we
> > ought to check for its existence first though.
> 
> I'll do it if you like.

There's no need to, IMHO.  I think Jim was wrong: symbols starting
with __ are indeed reserved for the implementation, but the meaning of
that reservation is that user code should not _define_ such symbols,
not that it must not use them.  In effect, this rule sets up a
namespace that the library implementation can use without risking that
it steps on the feet of user code.  But if we don't define any symbols
that begin with __, we are safe accessing them, I think.

I have no idea why the above comment from bits/signum.h was written.
I think it is wrong and the glibc maintainers should be asked to
either remove it or explain why they think these symbols should not be
used at user level.

Re: [linux] Always ignore restart/cancellation signals

[Daniel Jacobowitz]

On Fri, Dec 09, 2005 at 01:47:50PM +0200, Eli Zaretskii wrote:
> There's no need to, IMHO.  I think Jim was wrong: symbols starting
> with __ are indeed reserved for the implementation, but the meaning of
> that reservation is that user code should not _define_ such symbols,
> not that it must not use them.  In effect, this rule sets up a
> namespace that the library implementation can use without risking that
> it steps on the feet of user code.  But if we don't define any symbols
> that begin with __, we are safe accessing them, I think.

OK.

> I have no idea why the above comment from bits/signum.h was written.
> I think it is wrong and the glibc maintainers should be asked to
> either remove it or explain why they think these symbols should not be
> used at user level.

The comment is actually correct - for the vast majority of users of the
header.  I've long ago accepted that it's GDB's business to poke around
in the implementation :-)

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.  If you use the constant in the header for
anything, the implementation reserves the right to kick you when you're
down.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [linux] Always ignore restart/cancellation signals

[Daniel Jacobowitz]

On Fri, Dec 09, 2005 at 01:47:50PM +0200, Eli Zaretskii wrote:
> There's no need to, IMHO.  I think Jim was wrong: symbols starting
> with __ are indeed reserved for the implementation, but the meaning of
> that reservation is that user code should not _define_ such symbols,
> not that it must not use them.  In effect, this rule sets up a
> namespace that the library implementation can use without risking that
> it steps on the feet of user code.  But if we don't define any symbols
> that begin with __, we are safe accessing them, I think.

OK.

> I have no idea why the above comment from bits/signum.h was written.
> I think it is wrong and the glibc maintainers should be asked to
> either remove it or explain why they think these symbols should not be
> used at user level.

The comment is actually correct - for the vast majority of users of the
header.  I've long ago accepted that it's GDB's business to poke around
in the implementation :-)

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.  If you use the constant in the header for
anything, the implementation reserves the right to kick you when you're
down.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [linux] Always ignore restart/cancellation signals

[Eli Zaretskii]

> 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?

Re: [linux] Always ignore restart/cancellation signals

[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 <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 ())

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [linux] Always ignore restart/cancellation signals

[Eli Zaretskii]

> 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.

Re: [linux] Always ignore restart/cancellation signals

[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 <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

Re: [linux] Always ignore restart/cancellation signals

[Eli Zaretskii]

> Date: Fri, 9 Dec 2005 13:58:10 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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.

So you are saying that we should use __SIGRTMIN if we have no better
way of telling which signals are used, yes?  I agree.

Re: [linux] Always ignore restart/cancellation signals

[Mark Kettenis]

> Date: Fri, 9 Dec 2005 13:58:10 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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.

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

Re: [linux] Always ignore restart/cancellation signals

[Daniel Jacobowitz]

On Fri, Dec 09, 2005 at 09:49:05PM +0100, Mark Kettenis wrote:
> 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

Nowadays I believe they are always reserved; it's valid to dlopen
libpthread.so.

> numbers hardcoded in libpthread (in particular the NPTL one) or does
> it depend on whether there are other consumers of real-time signals?

They're hardcoded.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [linux] Always ignore restart/cancellation signals

[Mark Kettenis]

> Date: Fri, 9 Dec 2005 15:52:10 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Fri, Dec 09, 2005 at 09:49:05PM +0100, Mark Kettenis wrote:
> > 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
> 
> Nowadays I believe they are always reserved; it's valid to dlopen
> libpthread.so.
> 
> > numbers hardcoded in libpthread (in particular the NPTL one) or does
> > it depend on whether there are other consumers of real-time signals?
> 
> They're hardcoded.

Then it has my blessing ;-).

Mark

Re: [linux] Always ignore restart/cancellation signals

[Jim Blandy]

On 12/9/05, Eli Zaretskii <eliz@gnu.org> wrote:
> I think Jim was wrong:

No doubt, but what about?  :)

Re: [linux] Always ignore restart/cancellation signals

[Eli Zaretskii]

> Date: Fri, 9 Dec 2005 11:51:15 -0800
> From: Jim Blandy <jimb@red-bean.com>
> Cc: Kevin Buettner <kevinb@redhat.com>, gdb-patches@sources.redhat.com
> 
> On 12/9/05, Eli Zaretskii <eliz@gnu.org> wrote:
> > I think Jim was wrong:
> 
> No doubt, but what about?  :)

About the possibility to reference symbols that start with __ in user
code.

Re: [linux] Always ignore restart/cancellation signals

[Daniel Jacobowitz]

On Thu, Dec 08, 2005 at 09:24:20AM -0500, Daniel Jacobowitz wrote:
> The comment is fairly self-explanatory.  I guess I've always debugged
> failing cancellation tests with gdbserver, which hardwires these values
> already...
> 
> Any objections?

There were a few but they faded after discussion, so I have retested
and committed this patch.


-- 
Daniel Jacobowitz
CodeSourcery

2006-02-20  Daniel Jacobowitz  <dan@codesourcery.com>

	* linux-nat.c (lin_thread_get_thread_signals): Default to __SIGRTMIN
	and __SIGRTMIN + 1.

Index: gdb-6.4/gdb/linux-nat.c
===================================================================
--- gdb-6.4.orig/gdb/linux-nat.c	2005-11-03 14:51:40.000000000 -0500
+++ gdb-6.4/gdb/linux-nat.c	2005-12-07 21:44:12.000000000 -0500
@@ -3284,12 +3284,18 @@ lin_thread_get_thread_signals (sigset_t 
   sigemptyset (set);
 
   restart = get_signo ("__pthread_sig_restart");
+  cancel = get_signo ("__pthread_sig_cancel");
+
+  /* LinuxThreads normally uses the first two RT signals, but in some legacy
+     cases may use SIGUSR1/SIGUSR2.  NPTL always uses RT signals, but does
+     not provide any way for the debugger to query the signal numbers -
+     fortunately they don't change!  */
+
   if (restart == 0)
-    return;
+    restart = __SIGRTMIN;
 
-  cancel = get_signo ("__pthread_sig_cancel");
   if (cancel == 0)
-    return;
+    cancel = __SIGRTMIN + 1;
 
   sigaddset (set, restart);
   sigaddset (set, cancel);