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

[Pedro Alves <pedro@palves.net>]

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 <jhb@FreeBSD.org>
>>> 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".