Re: [PATCH 00/17] Interrupting programs that block/ignore SIGINT

[John Baldwin <jhb@FreeBSD.org>]

On 6/15/21 5:18 AM, Eli Zaretskii via Gdb-patches wrote:
>> From: Pedro Alves <pedro@palves.net>
>> 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 <pedro@palves.net>
>>>> 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 <pid>'.  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