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

[Eli Zaretskii]

> From: Pedro Alves <pedro@palves.net>
> Cc: gdb-patches@sourceware.org
> Date: Wed, 16 Jun 2021 12:27:28 +0100
> 
> Debugging curses programs works fine, because we "pump" all input/output between
> the terminals, escape sequences and all.  E.g., I use the TUI frequently, and
> debugging gdb with itself and enabling the TUI in the inferior gdb works fine.  
> No other pumping is done, only input/output.
> 
> When the new terminal is created, it inherits the terminal settings of the
> GDB terminal, but otherwise, the inferior's terminal settings are not
> reflected in GDB's terminal settings.  I mean, if the program changes \n -> \r\n
> translation in the inferior, that changes the inferior's terminal, and what ends
> up output to the pseudo-terminal slave end.  When GDB flushes that into its
> own terminal, GDB puts its own terminal in raw mode, so that exactly whatever
> characters/bytes the inferior wanted to send to the screen, they end up in
> GDB's terminal.  Similarly for the input direction.

That's good to hear, but it sounds like we aren't entirely sure which
features won't work with this arrangement, and are still going by
trial and error?  I hope by the time we release GDB 12, the
restrictions and other issues caused by this change will be
well-known, because we will need to document them, so users could know
in advance when they need to go back to the original behavior.

Or maybe I can persuade you to turn this feature off by default, at
least for GDB 12?

> Cut/paste works fine for me, but I'm not sure I'm trying what you are
> suggesting.

I meant the so-called "bracketed paste mode", see

  https://cirw.in/blog/bracketed-paste

> E.g., I debug a GDB that is running in TUI mode, and then I can use
> the mouse to select text (shift click drag) and then paste it back (shift middle click).
> This is all implemented in the terminal emulator, the application has no idea about it,
> it's just text grabbed from the screen, and then input back into the application,
> as if you typed it.

Yes, but some of these features need to be turned on before they can
be used.  The application (think: Emacs) does that for its terminal,
but not for the GDB terminal.

> Changing the interrupt character does not work.  If I debug emacs in text-mode, and
> then press ctrl-c, it drops you back into GDB, like:
> 
>  Thread 1 "emacs" stopped.
>  0x00007ffff5197246 in __pselect (nfds=9, readfds=0x7fffffffc8a0, writefds=0x7fffffffc920, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:48                                                           |
>  48      ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
>  (gdb)

This means that no Emacs key sequence that uses C-c will work under
GDB in this new mode, right?  In particular, "C-x C-c", which exits
Emacs?  That's why Emacs reprograms the terminal to use C-g instead.

> If I press "ctrl-g", I then get "Program stopped by SIGINT":
> 
>  Thread 1 "emacs" received signal SIGINT, Interrupt.
>  0x00007ffff5197246 in __pselect (nfds=9, readfds=0x7fffffffc8a0, writefds=0x7fffffffc920, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:48                                                           |
>  48      in ../sysdeps/unix/sysv/linux/pselect.c
>  (gdb)

Is this with the default setting in src/.gdbinit?  It says

  handle 2 noprint pass

And it does that for a reason: C-g is handled by the Emacs signal
handler.

> I see this as a feature and it goes back to the "supervisor" idea discussed
> in the other thread.  To change the "supervisor" interrupt key, you have to
> change the interrupt key in the supervisor's terminal, with e.g., "$ stty intr ^G".
> or even "(gdb) shell stty intr ^G".  Not unlike if you had attached to emacs
> instead of spawned it.  I guess the emacs's emacs-gdb.gdb file could run that
> stty command, so it is run automatically when debugging emacs.  The altered intr key will
> remain in effect after gdb exits, though.  (I can reproduce it with current GDB.)
> I guess GDB could grow a built-in command for that to avoid it.  

But that is only needed (or useful) if this new pseudo-tty mode is
being used, right?  How can this be expressed in a .gdbinit file, to
avoid sending unnecessary and potentially disruptive stty commands?