From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xLhAJSLMyWBSBQAAWB0awg (envelope-from ) for ; Wed, 16 Jun 2021 06:02:10 -0400 Received: by simark.ca (Postfix, from userid 112) id 8AF771F163; Wed, 16 Jun 2021 06:02:10 -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 350961E54D for ; Wed, 16 Jun 2021 06:02:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C807C398E47D for ; Wed, 16 Jun 2021 10:02:08 +0000 (GMT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by sourceware.org (Postfix) with ESMTPS id C4EF5383F435 for ; Wed, 16 Jun 2021 10:01:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C4EF5383F435 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-wm1-f45.google.com with SMTP id o39-20020a05600c5127b02901d23584fd9bso891094wms.0 for ; Wed, 16 Jun 2021 03:01:56 -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=UZ1sEtChgIYrzdTAv2Eper/QKkhrexJXh+I56TjKU7s=; b=OqayC1ncfQgjdLmeu4JGMrPshsYEY+JT8kY9EwgDPOzH3USaaBM2Z836G5sORipCdy W2bAR5tBE8HtXmuDibvtUayGQddw8xQY8FjWf/i5YY7kPIP7SCpVXtV0KbnaeiZmKpke L3x4PPdbRZfEyHJAv+HlRkoQryY7CvLJdUbekWlP1N+VESouYDjgQQjRwwbZDYzY9i7K S/GVWaGu/qI3mltPh67D0f74yJEOvrPhyqsGMK1BV2ZDwzoEzxZqgCkmeZa5N1R3B7T+ NVWXQqKR4OV5LvSehtdr0GfHzNMuSQqkmVp7My+tPCoy4rXAPjUN0ndVErNOUn2OGO4g 7/Og== X-Gm-Message-State: AOAM530r1XV74zwy02UqA/IhiMU3udCf9kAKdtGcAXdwENo8+ock04+6 B3K+/krOSzWFhweLgzEA5Cx5isvxnVL8Uw== X-Google-Smtp-Source: ABdhPJw41JtH5dxnryypTlYcmVWkJ1lkYenSHuLxO7FAKQx750PbRHEVtylOeBy+QfLAUoNm5axweQ== X-Received: by 2002:a1c:e91a:: with SMTP id q26mr10388619wmc.170.1623837714980; Wed, 16 Jun 2021 03:01:54 -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 m21sm4349390wms.42.2021.06.16.03.01.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 03:01:54 -0700 (PDT) Subject: Re: [PATCH 00/17] Interrupting programs that block/ignore SIGINT From: Pedro Alves To: John Baldwin , 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> Message-ID: Date: Wed, 16 Jun 2021 11:01:52 +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: <9c6bbbcc-82db-e487-a8cb-b6ca0a0c4268@FreeBSD.org> Content-Type: text/plain; charset=utf-8 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 2021-06-15 5:41 p.m., John Baldwin wrote: > On 6/15/21 9:18 AM, Eli Zaretskii wrote: >>> Cc: gdb-patches@sourceware.org >>> From: John Baldwin >>> Date: Tue, 15 Jun 2021 08:50:18 -0700 >>> >>> Put another way, every time I hit Ctrl-C when running a program under >>> GDB, the thought in my mind is not "I want to kill the program", it is >>> "I want to stop the program so I can examine its state in the debugger". >> >> So, in your opinion, Ctrl-C in this context is different from C-z and >> C-\, to name other keystrokes that cause signals to be delivered? > > Yes, due to the "supervisor" role of Ctrl-C and the fact I'm using it as > a GDB action.  FreeBSD has Ctrl-T (for SIGINFO) and I still view that > as an action on the inferior not a request to GDB, but Ctrl-C when > running under GDB is always in my mind "please ask GDB to stop the > program so I can inspect it", not "kill the program".  The fact that > the default is to not pass SIGINT seems consistent with this view since > doing a 'c' after the Ctrl-C resumes it rather than killing the > inferior.  One has to explicitly use 'kill' or 'signal' after a Ctrl-C > to interrupt the child process (vs just stop it). I really like the "supervisor" description here. Maybe I can sneak it in the documentation. The fact that SIGINT is nopass by default is a great point. It really shows that my patches don't change the behavior that much, really. Ctrl-C -> SIGINT -> c (not passed) Ctrl-C -> SIGINT -> signal SIGINT (SIGINT passed) vs Ctrl-C -> stopped -> c (not passed) Ctrl-C -> stopped -> signal SIGINT (SIGINT passed) It's only when you do "handle SIGINT pass": (gdb) handle SIGINT pass SIGINT is used by the debugger. Are you sure you want to change it? (y or n) y Signal Stop Print Pass to program Description SIGINT Yes Yes Yes Interrupt (and note how GDB warns you that SIGINT is special) that the behavior is different: Ctrl-C -> SIGINT -> c (SIGINT passed) Ctrl-C -> SIGINT -> signal SIGINT (SIGINT passed) vs Ctrl-C -> stopped -> c (nothing passed) Ctrl-C -> stopped -> signal SIGINT (SIGINT passed) > 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": "Suspending execution is done with the @code{interrupt} command when running in the background, or @kbd{Ctrl-c} during foreground execution. In all-stop mode, this stops the whole process; but in non-stop mode the interrupt applies only to the current thread. To stop the whole program, use @code{interrupt -a}." (gdb) help interrupt Interrupt the execution of the debugged program. If non-stop mode is enabled, interrupt only the current thread, otherwise all the threads in the program are stopped. To interrupt all running threads in non-stop mode, use the -a option. (gdb) help set may-interrupt Set permission to interrupt or signal the target. When this permission is on, GDB may interrupt/stop the target's execution. Otherwise, any attempt to interrupt or stop will be ignored. "interrupt" has been stopping the programs with just a plain non-signal "stopped." instead of "received SIGINT" for over a decade in non-stop mode. MI's -exec-interrupt: "Interrupts the background execution of the target." Or for example: @cindex tracepoints In some applications, it is not feasible for the debugger to interrupt the program's execution long enough for the developer to learn anything helpful about its behavior. If the program's correctness 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".