Re: [PATCH v2 16/16] Document pseudo-terminal and interrupting changes

[Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>]

> From: Pedro Alves <pedro@palves.net>
> Cc: gdb-patches@sourceware.org
> Date: Wed, 16 Jun 2021 11:15:38 +0100
> 
> >> +On systems where interrupting the program results in a plain
> >> +suspension instead of the program receiving a @code{SIGINT} signal,
> >> +you can still pass a @code{SIGINT} signal to the program after it
> >> +stops, using either the @code{signal SIGINT} or @code{queue-signal
> >> +SIGINT} commands.  @xref{Signaling,,Giving your Program a Signal}.
> > 
> > This begs a question I already asked elsewhere: I'd expect that
> > continuing the program after it was stopped like that will deliver
> > SIGINT to the program, without any special commands.  Isn't that so?
> > Your text seems to imply that it isn't, which I find surprising --
> > after all, the user pressed Ctrl-C, so "normally" the debuggee should
> > be hit with SIGINT, as if we were not debugging it.
> 
> This was discussed in the other thread, but what you're saying really isn't
> correct -- continuing the program after it was stopped doesn't normally
> make the the debuggee receive the SIGINT.  Only if you explicitly pass it,
> with special commands.

If you are talking about the default value of "handle SIGINT", then it
is still possible (and IMO advisable) to mention that the signal will
be passed to the debuggee, except that the default setting of SIGINT
handling purposefully prevents that.

> >> +@value{GDBN} on MS-Windows supports @kbd{C-@key{BREAK}} as an
> >> +alternative interrupt key sequence.  @xref{interrupt debuggee on
> >> +MS-Windows}.
> > 
> > I'm not sure I understand the significance of this note: after all, a
> > Windows program can install a Ctrl-BREAK handler exactly like it does
> > with Ctrl-C.  Is this only about SetConsoleMode?
> 
> I was creating a new "Interrupting" node in the manual, so I thought it
> was a good place to put cross references to other places in the manual
> that talk about interruption.  That's all this is.  Just like the
> reference to the remote debug section.

My point was more general: why are we taking such a great care
publishing the Ctrl-BREAK support?  What's the big deal?