From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id odsfFlzPyWDKBQAAWB0awg (envelope-from ) for ; Wed, 16 Jun 2021 06:15:56 -0400 Received: by simark.ca (Postfix, from userid 112) id 4AD8B1F163; Wed, 16 Jun 2021 06:15:56 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=MAILING_LIST_MULTI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 3E2EB1E54D for ; Wed, 16 Jun 2021 06:15:55 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7E115398EC19 for ; Wed, 16 Jun 2021 10:15:54 +0000 (GMT) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by sourceware.org (Postfix) with ESMTPS id B5137383B40F for ; Wed, 16 Jun 2021 10:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5137383B40F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f41.google.com with SMTP id a20so2058477wrc.0 for ; Wed, 16 Jun 2021 03:15:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RqG+E8KjYjZq8w3g8ej50PbdD41MV6CB1RmFKu8cbuQ=; b=HOeuzoy751IP7iyGD0Pe6OwcDxXGA245UwAt27/3x2XnDWbWEj1zC9JZR4RzlXbGDL c1/4NaVw4L4SSxM44BkTKhSP3y7FL5HzJXCXIEkEASx/GPfxjLVCMqJHx7yltFK07sCk y1MUTzvB0Q23HD5JnWkMj7Ou5Q8Uu5kZwNvQkW1SKfZ8/hJZoCg1xtSUHbBRninkLEi8 gRcpCQjwGVCOB9Lw0BPyYV/vlakBxvGVkVkpbPSH2Vtdr/OW2S22MupwwPMGIz7FDHUI rdM23XhTQ9pnxGedyePUuVzLiIRTzi5EvCTGu8csU0S33tp3AjhTupdE+rKlTV3OSg0X LzWQ== X-Gm-Message-State: AOAM530NEBybHGR51Q6CfwMOasxNW0WP+OaMMpHOvHBeH4krkNMg3Ixr sPbQnaUNYNBJ7eGE6I/s7io39wv5RTWw2g== X-Google-Smtp-Source: ABdhPJwcJJ+exb6o2T7Pj0z6TeGWVOKEAvkorIBxUAt1CAPRAIeFj8G46e8Q4C+qaOSHT5wQlXX/BA== X-Received: by 2002:a05:6000:1282:: with SMTP id f2mr4326333wrx.67.1623838540871; Wed, 16 Jun 2021 03:15:40 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3? ([2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3]) by smtp.gmail.com with ESMTPSA id 2sm1612425wrz.87.2021.06.16.03.15.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 03:15:39 -0700 (PDT) Subject: Re: [PATCH v2 16/16] Document pseudo-terminal and interrupting changes From: Pedro Alves To: Eli Zaretskii References: <20210614212410.1612666-1-pedro@palves.net> <20210614212410.1612666-17-pedro@palves.net> <83r1h34771.fsf@gnu.org> Message-ID: <86b228b3-31d1-103e-5c98-18a8a6032f2f@palves.net> Date: Wed, 16 Jun 2021 11:15:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83r1h34771.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Eli, It will take me a bit to actually go implement changes, but here are some responses. On 2021-06-15 1:56 p.m., Eli Zaretskii wrote: >> 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. Indeed. I think I'll drop the word "standard". > >> +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? Yeah, I'll take a fresh look. I was thinking that in the future other Unix hosts will be switched to use this feature as well, and we tend to forget updating such references in the manual. > > 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. 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. > >> +@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.