New command queue-signal.

If I want to change the signalled state of multiple threads
it's a bit cumbersome to do with the "signal" command.
What you really want is a way to set the signal state of the
desired threads and then just do "continue".

This patch adds a new command, queue-signal, to accomplish this.
Basically "signal N" == "queue-signal N" + "continue".
That's not precisely true in that "signal" can be used to inject
any signal, including signals set to "nopass"; whereas "queue-signal"
just queues the signal as if the thread stopped because of it.
"nopass" handling is done when the thread is resumed which
"queue-signal" doesn't do.

One could add extra complexity to allow queue-signal to be used to
deliver "nopass" signals like the "signal" command.  I have no current
need for it so in the interests of incremental complexity, I have
left such support out and just have the code flag an error if one
tries to queue a nopass signal.

gdb/ChangeLog:

	* NEWS: Mention new "queue-signal" command.
	* infcmd.c (queue_signal_command): New function.
	(_initialize_infcmd): Add new queue-signal command.

gdb/doc/ChangeLog:

	* gdb.texinfo (Signaling): Document new queue-signal command.

gdb/testsuite/ChangeLog:

	* gdb.threads/queue-signal.c: New file.
	* gdb.threads/queue-signal.exp: New file.

1 files changed, 26 insertions, 5 deletions

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index facbd16..037806f 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -16630,17 +16630,38 @@ same thread before issuing the @samp{signal 0} command.  If you issue
 the @samp{signal 0} command with another thread as the selected one,
 @value{GDBN} detects that and asks for confirmation.
 
-@code{signal} does not repeat when you press @key{RET} a second time
-after executing the command.
-@end table
-@c @end group
-
 Invoking the @code{signal} command is not the same as invoking the
 @code{kill} utility from the shell.  Sending a signal with @code{kill}
 causes @value{GDBN} to decide what to do with the signal depending on
 the signal handling tables (@pxref{Signals}).  The @code{signal} command
 passes the signal directly to your program.
 
+@code{signal} does not repeat when you press @key{RET} a second time
+after executing the command.
+
+@kindex queue-signal
+@item queue-signal @var{signal}
+Queue @var{signal} to be delivered immediately to the current thread
+when execution of the thread resumes.  The @var{signal} can be the name or
+the number of a signal.  For example, on many systems @code{signal 2} and
+@code{signal SIGINT} are both ways of sending an interrupt signal.
+The handling of the signal must be set to pass the signal to the program,
+otherwise @value{GDBN} will report an error.
+You can control the handling of signals from @value{GDBN} with the
+@code{handle} command (@pxref{Signals}).
+
+Alternatively, if @var{signal} is zero, any currently queued signal
+for the current thread is discarded and when execution resumes no signal
+will be delivered.  This is useful when your program stopped on account
+of a signal and would ordinarily see the signal when resumed with the
+@code{continue} command.
+
+This command differs from the @code{signal} command in that the signal
+is just queued, execution is not resumed.  And @code{queue-signal} cannot
+be used to pass a signal whose handling state has been set to @code{nopass}
+(@pxref{Signals}).
+@end table
+@c @end group
 
 @node Returning
 @section Returning from a Function