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

David Daney
2006-10-25T22:56:34Z

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