[rfc/remote] Tell remote stubs which signals are boring

[rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

Some time ago, I got a bug report that gdbserver couldn't be used to
debug a program.  You'd tell it to "continue", and it wouldn't - it
would just spin in place.

We realized eventually that the problem was SIGALRM.  There was a tiny
signal handler running every timer tick (at about 100Hz, if I remember
right).  That's plenty of time for native GDB to notice, resume, and
let the code run.  But if you have to stop the program, including any
threads, and send a packet over a socket to another machine, only to
have GDB tell you that you're not interested in it anyway, then you
never make any progress.  By the time the program returns from its
signal handler, SIGALRM is pending again.

This is the solution I came up with for that problem, adjusted to HEAD
and given a more sensible packet name.  I have a tested implementation
of this patch for HEAD, if my remote protocol choices are acceptable.
The new mechanism is completely transparent to the user.

All comments welcome!

`QPassSignals SIGNAL [;SIGNAL]...'
     Each listed SIGNAL, using the same signal numbering used in
     continue packets and stop responses, should be passed directly to
     the inferior process.  Each SIGNAL list item should be strictly
     greater than the previous item.  These signals do not need to stop
     the inferior, or be reported to GDB.  All other signals should be
     reported to GDB.  Multiple `QPassSignals' packets do not combine;
     any earlier `QPassSignals' list is completely replaced by the new
     list.  This packet improves performance when using `handle SIGNAL
     nostop noprint pass'.

     Reply:
    `OK'
          The request succeeded.

    `E NN'
          An error occurred.  NN are hex digits.

    `'
          An empty reply indicates that `QPassSignals' is not supported
          by the stub.

     Use of this packet is controlled by the `set remote pass-signals'
     command (*note set remote pass-signals: Remote configuration.).
     This packet is not probed by default; the remote stub must request
     it, by supplying an appropriate `qSupported' response (*note
     qSupported::).

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc/remote] Tell remote stubs which signals are boring

[Mark Kettenis]

> Date: Wed, 25 Oct 2006 17:24:41 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Some time ago, I got a bug report that gdbserver couldn't be used to
> debug a program.  You'd tell it to "continue", and it wouldn't - it
> would just spin in place.
> 
> We realized eventually that the problem was SIGALRM.  There was a tiny
> signal handler running every timer tick (at about 100Hz, if I remember
> right).  That's plenty of time for native GDB to notice, resume, and
> let the code run.  But if you have to stop the program, including any
> threads, and send a packet over a socket to another machine, only to
> have GDB tell you that you're not interested in it anyway, then you
> never make any progress.  By the time the program returns from its
> signal handler, SIGALRM is pending again.
> 
> This is the solution I came up with for that problem, adjusted to HEAD
> and given a more sensible packet name.  I have a tested implementation
> of this patch for HEAD, if my remote protocol choices are acceptable.
> The new mechanism is completely transparent to the user.
> 
> All comments welcome!

Makes sense to me.  There are native targets too that support
something similar; on Solaris you can tell the kernel what signals
you're interested in, and GDB will not even get the signals that are
"nostop noprint pass".

I hope someone who is more familiar with the remote protocol can say
something sane about the syntax you chose for the QPassSignals packet.

Mark

Re: [rfc/remote] Tell remote stubs which signals are boring

[David Daney]

Daniel Jacobowitz wrote:
> Some time ago, I got a bug report that gdbserver couldn't be used to
> debug a program.  You'd tell it to "continue", and it wouldn't - it
> would just spin in place.
> 
> We realized eventually that the problem was SIGALRM.  There was a tiny
> signal handler running every timer tick (at about 100Hz, if I remember
> right).  That's plenty of time for native GDB to notice, resume, and
> let the code run.  But if you have to stop the program, including any
> threads, and send a packet over a socket to another machine, only to
> have GDB tell you that you're not interested in it anyway, then you
> never make any progress.  By the time the program returns from its
> signal handler, SIGALRM is pending again.
> 
> This is the solution I came up with for that problem, adjusted to HEAD
> and given a more sensible packet name.  I have a tested implementation
> of this patch for HEAD, if my remote protocol choices are acceptable.
> The new mechanism is completely transparent to the user.
> 
> All comments welcome!
> 
> `QPassSignals SIGNAL [;SIGNAL]...'
>      Each listed SIGNAL, using the same signal numbering used in
>      continue packets and stop responses, should be passed directly to
>      the inferior process.  Each SIGNAL list item should be strictly
>      greater than the previous item.  These signals do not need to stop
>      the inferior, or be reported to GDB.  All other signals should be
>      reported to GDB.  Multiple `QPassSignals' packets do not combine;
>      any earlier `QPassSignals' list is completely replaced by the new
>      list.  This packet improves performance when using `handle SIGNAL
>      nostop noprint pass'.
> 
>      Reply:
>     `OK'
>           The request succeeded.
> 
>     `E NN'
>           An error occurred.  NN are hex digits.
> 
>     `'
>           An empty reply indicates that `QPassSignals' is not supported
>           by the stub.
> 
>      Use of this packet is controlled by the `set remote pass-signals'
>      command (*note set remote pass-signals: Remote configuration.).
>      This packet is not probed by default; the remote stub must request
>      it, by supplying an appropriate `qSupported' response (*note
>      qSupported::).

Does this mean that you have to issue a 'set remote pass-signals' 
command, or is it done automatically for 'handle noprint nostop pass' if 
the remote stub supports it?

Not being that familiar with the remote protocol, it is unclear to me.

David Daney

Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

On Wed, Oct 25, 2006 at 03:56:24PM -0700, David Daney wrote:
> >     Use of this packet is controlled by the `set remote pass-signals'
> >     command (*note set remote pass-signals: Remote configuration.).
> >     This packet is not probed by default; the remote stub must request
> >     it, by supplying an appropriate `qSupported' response (*note
> >     qSupported::).
> 
> Does this mean that you have to issue a 'set remote pass-signals' 
> command, or is it done automatically for 'handle noprint nostop pass' if 
> the remote stub supports it?
> 
> Not being that familiar with the remote protocol, it is unclear to me.

It will just work.  The conversation goes like this:

-> qSupported:			  # Whatcha got?
<- PacketSize=4000;QPassSignals+  # I got big buffers.  And stuff.
-> QPassSignals:e;10;14		  # Don't care about all these.
<- OK				  # OK, I don't care.
-> vCont:c			  # RUN!

The "set remote" command is only for overrides.  Honestly, I've been
thinking of removing the override commands, or moving them into maint
somewhere; they're half the trouble in adding and documenting a new
command, and we're just adding them for consistency at this point.
I don't think they're really useful except for testing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc/remote] Tell remote stubs which signals are boring

[Eli Zaretskii]

> Date: Wed, 25 Oct 2006 17:24:41 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> This is the solution I came up with for that problem, adjusted to HEAD
> and given a more sensible packet name.  I have a tested implementation
> of this patch for HEAD, if my remote protocol choices are acceptable.
> The new mechanism is completely transparent to the user.

I'm confused: shouldn't this packet be automatically sent to a remote
target when I say, e.g., "handle SIGALRM nostop noprint pass"?  Am I
missing something?

Re: [rfc/remote] Tell remote stubs which signals are boring

[Eli Zaretskii]

> Date: Wed, 25 Oct 2006 21:40:27 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> > 
> > Does this mean that you have to issue a 'set remote pass-signals' 
> > command, or is it done automatically for 'handle noprint nostop pass' if 
> > the remote stub supports it?
> > 
> > Not being that familiar with the remote protocol, it is unclear to me.
> 
> It will just work.

Then this should be mentioned in the manual, both where the new packet
and command are described, and where the "handle" command is
described.

Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

On Thu, Oct 26, 2006 at 02:57:29AM -0400, Eli Zaretskii wrote:
> > Date: Wed, 25 Oct 2006 17:24:41 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > This is the solution I came up with for that problem, adjusted to HEAD
> > and given a more sensible packet name.  I have a tested implementation
> > of this patch for HEAD, if my remote protocol choices are acceptable.
> > The new mechanism is completely transparent to the user.
> 
> I'm confused: shouldn't this packet be automatically sent to a remote
> target when I say, e.g., "handle SIGALRM nostop noprint pass"?  Am I
> missing something?

Now I'm confused :-)  Isn't that exactly what I said above?  It's
completely transparent; it just works.

On Thu, Oct 26, 2006 at 03:02:51AM -0400, Eli Zaretskii wrote:
> > It will just work.
> 
> Then this should be mentioned in the manual, both where the new packet
> and command are described, and where the "handle" command is
> described.

Can you expand on this?

Honestly, I have no idea what to say.  It's just a performance
optimization; it shouldn't affect the user experience at all.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc/remote] Tell remote stubs which signals are boring

[Eli Zaretskii]

> Date: Thu, 26 Oct 2006 08:18:39 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org, ddaney@avtrex.com
> 
> On Thu, Oct 26, 2006 at 02:57:29AM -0400, Eli Zaretskii wrote:
> > > Date: Wed, 25 Oct 2006 17:24:41 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > This is the solution I came up with for that problem, adjusted to HEAD
> > > and given a more sensible packet name.  I have a tested implementation
> > > of this patch for HEAD, if my remote protocol choices are acceptable.
> > > The new mechanism is completely transparent to the user.
> > 
> > I'm confused: shouldn't this packet be automatically sent to a remote
> > target when I say, e.g., "handle SIGALRM nostop noprint pass"?  Am I
> > missing something?
> 
> Now I'm confused :-)  Isn't that exactly what I said above?  It's
> completely transparent; it just works.

Perhaps I'm too dumb today, but ``completely transparent'' does not
tell me that there's any connection between `handle' and `set remote
pass-signals', especially since an interactive command can hardly be
described as ``transparent to the user''.

> > Then this should be mentioned in the manual, both where the new packet
> > and command are described, and where the "handle" command is
> > described.
> 
> Can you expand on this?
> 
> Honestly, I have no idea what to say.  It's just a performance
> optimization; it shouldn't affect the user experience at all.

We are talking about 2 user commands which are related.  That relation
should be mentioned in the manual.  Without that, a user could turn
off the new packet and not understand that this could do harm when the
inferior uses signals.

Here's another way to look at the issue: suppose this patch is already
in GDB, and suppose you are J. Random Hacker who experiences the
problem that originally caused you to write the patch--how would you
know to toggle `set remote pass-signals' to try to see if that is the
cause of your trouble?  I think, if the description of `handle' has an
xref to the description of `set remote pass-signals', you'd find that
info much quicker and more reliably.

If this is still unclear, I'll fix it myself once it's in CVS, and
post the patch here in the hope that it'd be clear then.

Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

On Thu, Oct 26, 2006 at 11:01:18AM -0400, Eli Zaretskii wrote:
> > On Thu, Oct 26, 2006 at 02:57:29AM -0400, Eli Zaretskii wrote:
> > > > Date: Wed, 25 Oct 2006 17:24:41 -0400
> > > > From: Daniel Jacobowitz <drow@false.org>
> > > > 
> > > > This is the solution I came up with for that problem, adjusted to HEAD
> > > > and given a more sensible packet name.  I have a tested implementation
> > > > of this patch for HEAD, if my remote protocol choices are acceptable.
> > > > The new mechanism is completely transparent to the user.
> > > 
> > > I'm confused: shouldn't this packet be automatically sent to a remote
> > > target when I say, e.g., "handle SIGALRM nostop noprint pass"?  Am I
> > > missing something?
> > 
> > Now I'm confused :-)  Isn't that exactly what I said above?  It's
> > completely transparent; it just works.
> 
> Perhaps I'm too dumb today, but ``completely transparent'' does not
> tell me that there's any connection between `handle' and `set remote
> pass-signals', especially since an interactive command can hardly be
> described as ``transparent to the user''.

It's transparent because you should never, ever have to use "set
remote pass-signals".  If the target reports that it supports
QPassSignals, it will be used automatically.  If it doesn't report it,
then forcing it on isn't going to work, unless the remote target is
buggy (supports the packet but claims not to).  Disabling it is,
again, not useful unless the remote target is buggy (supports the
packet but mishandles it).

This is one of the reasons I mentioned in another message yesterday
that I was thinking of removing or moving to "maint" the various "set
remote" packet controls - they're confusing.  Best would probably be to
both move and rename them: "set remote pass-signals-packet" would
become "maint set remote QPassSignals", with a clear correspondence to
the packet it controls.  It's a design feature of the remote protocol
that everything is autonegotiated, so (just as currently), these would
all default to an "auto" setting.

WDYT?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc/remote] Tell remote stubs which signals are boring

[Eli Zaretskii]

> Date: Thu, 26 Oct 2006 11:10:06 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org, ddaney@avtrex.com
> 
> It's transparent because you should never, ever have to use "set
> remote pass-signals".  If the target reports that it supports
> QPassSignals, it will be used automatically.  If it doesn't report it,
> then forcing it on isn't going to work, unless the remote target is
> buggy (supports the packet but claims not to).  Disabling it is,
> again, not useful unless the remote target is buggy (supports the
> packet but mishandles it).

This sounds like a good reason not to have the command at all.

If we decide not to install that part of the patch, my request is a
moot point, but as long as the command is described in the manual,
please add the mutual cross-references between it and `handle'.

> This is one of the reasons I mentioned in another message yesterday
> that I was thinking of removing or moving to "maint" the various "set
> remote" packet controls - they're confusing.  Best would probably be to
> both move and rename them: "set remote pass-signals-packet" would
> become "maint set remote QPassSignals", with a clear correspondence to
> the packet it controls.  It's a design feature of the remote protocol
> that everything is autonegotiated, so (just as currently), these would
> all default to an "auto" setting.
> 
> WDYT?

Sounds convincing to me, assuming that auto-negotiated settings never
lie about the support and seldom have bugs that make them not useful.
I'm not in a position to say whether this is true, since I don't have
enough experience with debugging remote targets.

Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

On Thu, Oct 26, 2006 at 11:18:31AM -0400, Eli Zaretskii wrote:
> Sounds convincing to me, assuming that auto-negotiated settings never
> lie about the support and seldom have bugs that make them not useful.
> I'm not in a position to say whether this is true, since I don't have
> enough experience with debugging remote targets.

I think that matches my experience.  I'll work on such a change now.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc/remote] Tell remote stubs which signals are boring

[Mark Kettenis]

>  On Thu, Oct 26, 2006 at 02:57:29AM -0400, Eli Zaretskii wrote:
> > > Date: Wed, 25 Oct 2006 17:24:41 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > >
> > > This is the solution I came up with for that problem, adjusted to HEAD
> > > and given a more sensible packet name.  I have a tested implementation
> > > of this patch for HEAD, if my remote protocol choices are acceptable.
> > > The new mechanism is completely transparent to the user.
> >
> > I'm confused: shouldn't this packet be automatically sent to a remote
> > target when I say, e.g., "handle SIGALRM nostop noprint pass"?  Am I
> > missing something?
>
>  Now I'm confused :-)  Isn't that exactly what I said above?  It's
>  completely transparent; it just works.

Perhaps I should even add more confusing statements to that.  What if I say
"handle SIGALRM nostop noprint pass" after I've connected to the remote
target.  Will it send a new  QPassSignals packet when I do that?  AFAICT
from your patch it doesn't do that, and that seems broken to me.

Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

On Thu, Oct 26, 2006 at 05:27:11PM +0200, Mark Kettenis wrote:
> Perhaps I should even add more confusing statements to that.  What if I say
> "handle SIGALRM nostop noprint pass" after I've connected to the remote
> target.  Will it send a new  QPassSignals packet when I do that?  AFAICT
> from your patch it doesn't do that, and that seems broken to me.

In fact it will do that.  We check that the most recently sent
QPassSignals packet matches the current set of ignored signals
at every resume.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc/remote] Tell remote stubs which signals are boring

[Mark Kettenis]

> Date: Thu, 26 Oct 2006 11:37:32 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Thu, Oct 26, 2006 at 05:27:11PM +0200, Mark Kettenis wrote:
> > Perhaps I should even add more confusing statements to that.  What if I say
> > "handle SIGALRM nostop noprint pass" after I've connected to the remote
> > target.  Will it send a new  QPassSignals packet when I do that?  AFAICT
> > from your patch it doesn't do that, and that seems broken to me.
> 
> In fact it will do that.  We check that the most recently sent
> QPassSignals packet matches the current set of ignored signals
> at every resume.

Cool!

Re: [rfc/remote] Tell remote stubs which signals are boring

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> Some time ago, I got a bug report that gdbserver couldn't be used to
> debug a program.  You'd tell it to "continue", and it wouldn't - it
> would just spin in place.
>
> We realized eventually that the problem was SIGALRM.  There was a tiny
> signal handler running every timer tick (at about 100Hz, if I remember
> right).  That's plenty of time for native GDB to notice, resume, and
> let the code run.  But if you have to stop the program, including any
> threads, and send a packet over a socket to another machine, only to
> have GDB tell you that you're not interested in it anyway, then you
> never make any progress.  By the time the program returns from its
> signal handler, SIGALRM is pending again.
>
> This is the solution I came up with for that problem, adjusted to HEAD
> and given a more sensible packet name.  I have a tested implementation
> of this patch for HEAD, if my remote protocol choices are acceptable.
> The new mechanism is completely transparent to the user.
>
> All comments welcome!
>
> `QPassSignals SIGNAL [;SIGNAL]...'

(Thanks, Mark, for asking about this!)  Please don't use a space to
mark the end of the packet name.  At the moment, the remote protocol
documentation uses spaces just for clarity; if they become meaningful,
then we're going to have to revamp our manual notation --- again.

The text in "Overview" suggests using ',', ';', or ':'.


>      Each listed SIGNAL, using the same signal numbering used in

I'd like to see "and syntax" added here --- I assume that's so?

Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

On Thu, Oct 26, 2006 at 02:11:25PM -0700, Jim Blandy wrote:
> (Thanks, Mark, for asking about this!)  Please don't use a space to
> mark the end of the packet name.  At the moment, the remote protocol
> documentation uses spaces just for clarity; if they become meaningful,
> then we're going to have to revamp our manual notation --- again.
> 
> The text in "Overview" suggests using ',', ';', or ':'.

Typo in the documentation.  The top of the general query packets page
is quite clear that it ought to be a colon, and so it is.  Thanks.

> >      Each listed SIGNAL, using the same signal numbering used in
> 
> I'd like to see "and syntax" added here --- I assume that's so?

How much syntax is there to a single number?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc/remote] Tell remote stubs which signals are boring

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Thu, Oct 26, 2006 at 02:11:25PM -0700, Jim Blandy wrote:
>> (Thanks, Mark, for asking about this!)  Please don't use a space to
>> mark the end of the packet name.  At the moment, the remote protocol
>> documentation uses spaces just for clarity; if they become meaningful,
>> then we're going to have to revamp our manual notation --- again.
>> 
>> The text in "Overview" suggests using ',', ';', or ':'.
>
> Typo in the documentation.  The top of the general query packets page
> is quite clear that it ought to be a colon, and so it is.  Thanks.
>
>> >      Each listed SIGNAL, using the same signal numbering used in
>> 
>> I'd like to see "and syntax" added here --- I assume that's so?
>
> How much syntax is there to a single number?

Well, the numbers might be in the passive voice.  Or something.

I had in mind fixed-width vs. variable-width.  Fixed-width is used for
signal numbers in the response packets, so I think there's room for
confusion.  Signal numbers in the step and continue packets are
documented to be variable-width hex, which is safely permissive; all
I'm suggesting is that those two words be added.

I have run into width concerns working with other parts of the
protocol (for example, with register values in T responses ---
although that's target byte order so it's a bit different), so I think
it's worth something to be explicit.

Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz]

On Thu, Oct 26, 2006 at 02:28:38PM -0700, Jim Blandy wrote:
> Well, the numbers might be in the passive voice.  Or something.
> 
> I had in mind fixed-width vs. variable-width.  Fixed-width is used for
> signal numbers in the response packets, so I think there's room for
> confusion.  Signal numbers in the step and continue packets are
> documented to be variable-width hex, which is safely permissive; all
> I'm suggesting is that those two words be added.
> 
> I have run into width concerns working with other parts of the
> protocol (for example, with register values in T responses ---
> although that's target byte order so it's a bit different), so I think
> it's worth something to be explicit.

Ah, it's variable-width.  But the overview says this:

Except where otherwise noted all numbers are represented in HEX with
leading zeros suppressed.

-- 
Daniel Jacobowitz
CodeSourcery