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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> 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