From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id B48073850416 for ; Wed, 16 Jun 2021 12:45:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B48073850416 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39500) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ltUvK-0000wz-RM; Wed, 16 Jun 2021 08:45:38 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2174 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ltUvK-00044n-FV; Wed, 16 Jun 2021 08:45:38 -0400 Date: Wed, 16 Jun 2021 15:45:39 +0300 Message-Id: <835yye2d1o.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: (message from Pedro Alves on Wed, 16 Jun 2021 12:27:28 +0100) Subject: Re: [PATCH v2 00/16] Interrupting programs that block/ignore SIGINT References: <20210614212410.1612666-1-pedro@palves.net> <83sg1j488r.fsf@gnu.org> X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, URIBL_SBL, URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 12:45:41 -0000 > From: Pedro Alves > 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=, sigmask=) 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=, sigmask=) 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?