From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id lrsbEqujyGDmZgAAWB0awg (envelope-from ) for ; Tue, 15 Jun 2021 08:57:15 -0400 Received: by simark.ca (Postfix, from userid 112) id 3BD4F1F163; Tue, 15 Jun 2021 08:57:15 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 182CC1E939 for ; Tue, 15 Jun 2021 08:57:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8BF843893657 for ; Tue, 15 Jun 2021 12:57:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BF843893657 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623761833; bh=ctKz48wwqpDsJ3vTohKpATiqlQv+5I5Cboot3OAuVcQ=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=e3hvw8hIdWw4V82zZEe3SKbzynxO+G1vA2J7HHSJBz4wYXUUfcxiOq/oT9hfex96K TcFRU1RzSzl1ZSFn6Gn8OjT8+F205G59KuHpLDWLYmhYXTvpQBhxC8GeM8YUxlEshJ 3PIsXYGUPkdWB96+tp8tY6HEN3asZYJHfmwGsOrc= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id CCC043857420 for ; Tue, 15 Jun 2021 12:56:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCC043857420 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52398) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lt8ce-0001k5-8B; Tue, 15 Jun 2021 08:56:52 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2102 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 1lt8cd-0002M4-SM; Tue, 15 Jun 2021 08:56:52 -0400 Date: Tue, 15 Jun 2021 15:56:50 +0300 Message-Id: <83r1h34771.fsf@gnu.org> To: Pedro Alves In-Reply-To: <20210614212410.1612666-17-pedro@palves.net> (message from Pedro Alves on Mon, 14 Jun 2021 22:24:10 +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> 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: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > From: Pedro Alves > Date: Mon, 14 Jun 2021 22:24:10 +0100 > > +Depending on the operating system and configuration, either: > + > +@itemize > + > +@item > +@value{GDBN} switches the terminal to its own terminal modes to > +interact with you, but it records the terminal modes your program was > +using and switches back to them when you continue running your > +program. This is the default on most systems. > + > +@item > +@value{GDBN} creates a pseudo-terminal, sets your program to use it > +for standard input and standard output, and forwards input and output > +to and from @value{GDBN}'s terminal at appropriate times. This is the > +default on GNU/Linux. This doesn't read well. I suggest to make "Either" and "Or" part of the text, like this: Depending on the operating system and configuration: @itemize @item Either @value{GDBN} switches the terminal ... @item Or @value{GDB} creates a pseudo-terminal ... > +@value{GDBN} creates a pseudo-terminal, sets your program to use it > +for standard input and standard output ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This begs the question about the standard error stream. > +On some operating systems, by default, @value{GDBN} creates a > +pseudo-terminal, and sets your program to use it for standard input > +and standard output. @value{GDBN} takes care of forwarding input and > +output to and from @value{GDBN}'s terminal at appropriate times, so > +this is largely transparent. The 2 different behaviors are described somewhat inconsistently: in one place you say "most systems" vs "GNU/Linux", in another place "some operating systems" instead of "GNU/Linux", and in yet another place you say "on systems where GDB creates a pseudo-terminal". Can you describe the pseudo-terminal feature consistently as a GNU/Linux feature? Also, describing the feature in a single place, and just having a cross-reference to there in other places will go a long way towards making the description clear and complete. > +On such systems, in some cases, like for example if you need to run > +your program and then detach it, and you want the program to remain > +associated with a terminal, you may prefer that @value{GDBN} starts > +your program using the same device for standard input and output as > +@value{GDBN} is using. IMHO, this is a misfeature. If the terminal from which GDB was run remains on the system, it would be an unpleasant surprise for the user that the program gets hit by SIGHUP when you detach. I think we should try to avoid this side effect, if that's feasible. > +@node Interrupting > +@section Interrupting Once again, I'd prefer to talk about "stopping" instead. Or maybe even "getting control to GDB". > +Depending on operating system and configuration, this results in > +interrupting the program with either a @code{SIGINT} signal: > + > +@smallexample > +Program received signal SIGINT, Interrupt. > +@end smallexample > + > +@noindent > +or plainly suspending the program: > + > +@smallexample > +Program stopped. > +@end smallexample This seems to be inaccurate. On MS-Windows, for example, I see something different: Thread 4 received signal SIGTRAP, Trace/breakpoint trap. So maybe you want to say that the above is only true for Posix hosts. Or maybe just be more vague and don't try quoting the messages? > +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. > +@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? Thanks.