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

[David Daney <ddaney@avtrex.com>]

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