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 A4A3C385E823 for ; Wed, 16 Jun 2021 12:15:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A4A3C385E823 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38988) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ltUS5-0002Hs-W4; Wed, 16 Jun 2021 08:15:26 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4286 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 1ltURw-0005px-31; Wed, 16 Jun 2021 08:15:25 -0400 Date: Wed, 16 Jun 2021 15:15:19 +0300 Message-Id: <83a6nq2eg8.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <86b228b3-31d1-103e-5c98-18a8a6032f2f@palves.net> (message from Pedro Alves on Wed, 16 Jun 2021 11:15:38 +0100) Subject: Re: [PATCH v2 16/16] Document pseudo-terminal and interrupting changes References: <20210614212410.1612666-1-pedro@palves.net> <20210614212410.1612666-17-pedro@palves.net> <83r1h34771.fsf@gnu.org> <86b228b3-31d1-103e-5c98-18a8a6032f2f@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: Wed, 16 Jun 2021 12:15:28 -0000 > From: Pedro Alves > 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?