This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [rfc/remote] Tell remote stubs which signals are boring
- From: Jim Blandy <jimb at codesourcery dot com>
- To: gdb at sourceware dot org
- Date: Thu, 26 Oct 2006 14:11:25 -0700
- Subject: Re: [rfc/remote] Tell remote stubs which signals are boring
- References: <20061025212441.GA622@nevyn.them.org>
Daniel Jacobowitz <drow@false.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?