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 8EBBC3857420 for ; Tue, 15 Jun 2021 12:34:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8EBBC3857420 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51880) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lt8Gk-0004mW-3t; Tue, 15 Jun 2021 08:34:14 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4644 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 1lt8Gj-0008R1-OG; Tue, 15 Jun 2021 08:34:14 -0400 Date: Tue, 15 Jun 2021 15:34:12 +0300 Message-Id: <83sg1j488r.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <20210614212410.1612666-1-pedro@palves.net> (message from Pedro Alves on Mon, 14 Jun 2021 22:23:54 +0100) Subject: Re: [PATCH v2 00/16] Interrupting programs that block/ignore SIGINT References: <20210614212410.1612666-1-pedro@palves.net> X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP 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: Tue, 15 Jun 2021 12:34:16 -0000 > From: Pedro Alves > 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?