Re: [PATCH v2 00/16] Interrupting programs that block/ignore SIGINT

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

> From: Pedro Alves <pedro@palves.net>
> Date: Mon, 14 Jun 2021 22:23:54 +0100
> 
> Currently, on GNU/Linux, it is not possible to interrupt with Ctrl-C
> programs that block or ignore SIGINT, with e.g., sigprocmask or
> signal(SIGINT, SIG_IGN).  You type Ctrl-C, but nothing happens.

For the reasons I explained in my other message, can we please talk
about "stopping a program" instead of "interrupting"?  Both in the log
message (and the discussion) and in the documentation, please.  At
least for me, the use of "interrupt" was confusing.

> This series address the problem by turning Ctrl-C handling around such
> that the SIGINT always reaches GDB first, not the inferior.  That is
> done by making GDB put inferiors in their own terminal/session created
> by GDB.  I.e., GDB creates a pseudo-terminal master/slave pair, makes
> the inferior run with the slave as its terminal, and pumps
> output/input on the master end.

Is this "pumping" really-truly 100% transparent to the program being
debugged?  I understand how a program that uses stdio will simply read
the same stuff that was "pumped" from GDB's terminal, but what about
other kinds of input and settings?

For example, some text-mode programs change the settings of the
terminal via termios -- will those settings be reflected in the GDB's
terminal when the debuggee reads or writes from its terminal?  Or what
about support for terminfo functions -- will the commands be passed
back and forth between the terminals and the user will see the effects
he/she expects?  Some terminal emulators support advanced features
like cut/paste -- will that also work with this pumping?  And if the
program changes the character that causes SIGINT (Emacs does that when
it runs on a text-mode terminal), will that change the interrupt
character for GDB as well?

> The series will then make GDB interrupt the program with SIGSTOP
> instead of SIGINT, which always works even if the inferior
> blocks/ignores SIGINT -- SIGSTOP can't be ignored.

And if the user then types "continue", will SIGINT be delivered to the
program, or will the Ctrl-C keystroke be "swallowed" by GDB?

> Having the inferior in its own terminal also means that GDB is in
> control of when inferior output is flushed to the screen.  When
> debugging with the CLI, this means that inferior output is now never
> interpersed with GDB's output in an unreadable fashion.

I guess this will be done on the screen line level?  Because if a
program uses terminfo or curses to write to different parts of the
screen, the outputs of the program and GDB will mix anyhow, just not
on the same screen line, right?