From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id drbpKJMTymAcDwAAWB0awg (envelope-from ) for ; Wed, 16 Jun 2021 11:06:59 -0400 Received: by simark.ca (Postfix, from userid 112) id 99B8A1F163; Wed, 16 Jun 2021 11:06:59 -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 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 84A641E939 for ; Wed, 16 Jun 2021 11:06:58 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CAEEB3948A71 for ; Wed, 16 Jun 2021 15:06:57 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 7EE0C383A802 for ; Wed, 16 Jun 2021 15:06:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7EE0C383A802 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id EACE39137F; Wed, 16 Jun 2021 15:06:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4pS561Vsz4YYV; Wed, 16 Jun 2021 15:06:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 5B5DE5845; Wed, 16 Jun 2021 15:06:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Pedro Alves , Eli Zaretskii References: <20210603190243.2609886-1-pedro@palves.net> <835yyuwwuu.fsf@gnu.org> <2af9e861-69f2-80c5-606b-2936b6d2d212@palves.net> <83tulz48yr.fsf@gnu.org> <83bl873xuu.fsf@gnu.org> <9c6bbbcc-82db-e487-a8cb-b6ca0a0c4268@FreeBSD.org> From: John Baldwin Subject: Re: [PATCH 00/17] Interrupting programs that block/ignore SIGINT Message-ID: <32b429c9-2c4d-dfa6-9113-69d1133c2232@FreeBSD.org> Date: Wed, 16 Jun 2021 08:06:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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" On 6/16/21 3:01 AM, Pedro Alves wrote: > On 2021-06-15 5:41 p.m., John Baldwin wrote: >> I do think it probably is clearer to use "stop" instead of "interrupt" >> as you noted though since the "interrupted" term is a bit overloaded >> and thus ambiguous. > > I was just thinking of "interrupting" as in the dictionary English term for > "stop the continuous progress of (an activity or process)." > > I'll go over the manual changes and switch to use "stop" instead when it seems > easy enough. > > But note that the cat is out of the bag for many years now, and GDB and the manual > already use "interrupt" pervasively to mean suspend/stop. For example, > the CLI command to stop a program is "interrupt": Ah, oh well. It is true that "interrupt" is a pretty general term (e.g. for device interrupts it is not specific to any specific device, and signals are effectively software interrupts in user mode, though many of them are synchronous (SIGSEGV, etc.) and thus more traps/exceptions rather than interrupts (which are usually used for asynchronous events)). > So maybe the right thing to do is not the avoid the work "interrupt" altogether > which seems impossible, but to clarify better what it means in the > new "Interrupting" node. > > For example, I had: > > @menu > * Breakpoints:: Breakpoints, watchpoints, and catchpoints > * Continuing and Stepping:: Resuming execution > +* Interrupting:: Interrupting execution > * Skipping Over Functions and Files:: > Skipping over functions and files > * Signals:: Signals > @@ -6376,6 +6442,45 @@ default is @code{on}. > > @end table > > +@node Interrupting > +@section Interrupting > + > +You can stop the program while it is running in the foreground by > +pressing the interrupt character (often @kbd{Ctrl-c}). If the program > +is executing in the background (@pxref{Background Execution}), you can > +use the @code{interrupt} command (@pxref{interrupt}). > > (note how the "interrupt" command appears here) > > I can see about making it clear that this interruption is mostly transparent > to the program, other than timing issues, and maybe EINTR. That if you want to > affect an interrupt in the program itself, you should "signal SIGINT". Ok, this sounds good to me. -- John Baldwin