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

[Daniel Jacobowitz <drow at false dot 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!

`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