From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xpC0J0nMyGD9agAAWB0awg (envelope-from ) for ; Tue, 15 Jun 2021 11:50:33 -0400 Received: by simark.ca (Postfix, from userid 112) id 94E651F163; Tue, 15 Jun 2021 11:50:33 -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 A54781E939 for ; Tue, 15 Jun 2021 11:50:32 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E65E03853800 for ; Tue, 15 Jun 2021 15:50:31 +0000 (GMT) Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 3073B3857C4F for ; Tue, 15 Jun 2021 15:50:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3073B3857C4F 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 DC95F793D1; Tue, 15 Jun 2021 15:50:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4G4CSr5fwxz4W4S; Tue, 15 Jun 2021 15:50:20 +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 5609629F13; Tue, 15 Jun 2021 15:50:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Eli Zaretskii , Pedro Alves References: <20210603190243.2609886-1-pedro@palves.net> <835yyuwwuu.fsf@gnu.org> <2af9e861-69f2-80c5-606b-2936b6d2d212@palves.net> <83tulz48yr.fsf@gnu.org> From: John Baldwin Subject: Re: [PATCH 00/17] Interrupting programs that block/ignore SIGINT Message-ID: Date: Tue, 15 Jun 2021 08:50:18 -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: <83tulz48yr.fsf@gnu.org> 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/15/21 5:18 AM, Eli Zaretskii via Gdb-patches wrote: >> From: Pedro Alves >> Cc: gdb-patches@sourceware.org >> Date: Mon, 14 Jun 2021 18:55:17 +0100 >> >> On 2021-06-03 8:51 p.m., Eli Zaretskii wrote: >>>> From: Pedro Alves >>>> Date: Thu, 3 Jun 2021 20:02:26 +0100 >>>> >>>> Currently, on GNU/Linux, it is not possible to interrupt with Ctrl-C >>>> programs that block or ignore SIGINT, with e.g., sigprocmask or >>>> signal(SIGINT, SIG_IGN). You type Ctrl-C, but nothing happens. >>> >>> I'm not sure I understand why this is a problem. If a debuggee blocks >>> or ignores SIGINT, then SIGINT cannot be used to stop it, neither when >>> it runs outside the debugger nor when it runs under a debugger. There >>> are enough other methods to stop such a debuggee (e.g., send it a >>> different signal), but basically such a program clearly tells that it >>> doesn't want to be interrupted by SIGINT, period. >> >> It sounds like you're taking the view that Ctrl-C should be seen by the >> inferior first, and behave exactly as if you were not debugging >> the program? >> >> My view is that, as a user, I see Ctrl-C as the standard way across configurations >> to interrupt programs so I can inspect them. When I type Ctrl-C, I'm telling >> GDB that I want to stop the program. > > Actually, my original problem was caused by your use of "interrupt a > program", when what you actually meant (AFAIU now) was "stop the > program". This was what originally set me off: the above text you > posted as the preamble for your patch reads like it's saying that > something is wrong with the situation where programs that don't want > to be interrupted by Ctrl-C can't be interrupted by SIGINT under GDB. > Thus my reaction. > > However, thinking about the issue some more, now that I understand > what you meant, I do indeed think that programs which block or ignore > SIGINT should not be stopped by Ctrl-C under GDB. The reason is > simple: SIGINT is just another fatal signal. Any fatal signal > delivered to a program being debugged will not stop the program if the > program blocks or ignores that signal, right? So why should SIGINT be > special? > > IOW, Are you sure your expectations are not based on old habits, where > "normally" Ctrl-C can be used to stop a debuggee, and thus it is a > convenient means of doing so? > > I wonder how many others here think like you and how many think like > me. If I'm the odd one out, then I won't continue talking about this > aspect of your patches. > > I'm glad you found a way of making the effects of these changes less > surprising, but I still have a couple of issues with the changes, > which I will raise in response to your v2. I would really like it if Ctrl-C always stopped the debuggee. Consider when attaching to an existing process via 'attach '. That always stops the process regardless of what signals it does or doesn't have masked. This of course uses SIGSTOP (which is not maskable) not SIGINT to stop the inferior. I think I view Ctrl-C in the window where I'm running GDB as Pedro does: a command to GDB rather than to the inferior. When running something directly under GDB via run, I view GDB as a kind of "supervisor" of the inferior, and Ctrl-C is one of the "supervisor" hooks in my mind. I don't know that there are many others, but as a user I want some fail-safe to always be able to stop the program I'm debugging. 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". -- John Baldwin