Tell remote stubs which signals are boring

Daniel Jacobowitz <drowfalse.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?