'interrupt' command usecase in all-stop mode.

[Pedro Alves]

On 12/8/20 2:53 PM, Andrew Burgess wrote:
> * Bilal, Muhammad <Muhammad_Bilal@mentor.com> [2020-12-07 13:18:02 +0000]:
> 
>> Hi,
>>
>> I want to confirm gdb 'interrupt' command usecase in all stop mode.
>>
>> Eclipse cdt only uses gdb interrupt command with new-ui command
>> otherwise it use Ctrl-C signal.
>>
>> On Windows host cdt does not support new-ui command, so that's why
>> it uses Ctrl-C signal to interrupt the process but that's create a
>> problem.
>>  
>> As you know, on running target if gdb owns the terminal settings and
>> user try to suspend the application then GDB doesn't pass the Ctrl-C
>> to inferior and just QUIT the process (do there is no MI record),
> In synchronous mode, when GDB owns the terminal this means that GDB is
> doing "stuff" and the target is stopped.  So if a SIGINT (from Ctrl-C)
> arrives at this point you are correct that GDB does not need to
> interrupt the target.
> 
> However, my expectation would be that GDB should still issue a stop
> even through the MI.  Consider this series of events:
> 
>   1. User issues -exec-continue
>   2. GDB prepares the target to resume
>   3. target is actually set executing
>   4. target stops (hit a b/p maybe)
>   5. GDB notices the stop and does internal book keeping
>   6. GDB prints a prompt and waits for user input.
> 
> During steps 2 and 5 GDB will own the terminal.  At some point during
> phase 2 GDB will emit the running/started event, and during phase 5
> GDB will emit the stopped event.
> 
> In phase 2 once the running/started event has been emitted then the
> GDB should consider the target running, if a SIGINT arrives then GDB
> should always emit a stopped event.

Yes.

> 
> Similarly in phase 5, before the stopped event is emitted, a SIGINT
> should not cause GDB to skip emitting the stop event.

Yes.

> 
> If this isn't happening then this feels like a bug (to me) as it
> renders the stop events useless as a mechanism to reliably detect when
> the target is stopped.

Right, it should be happening, modulo bugs.

I spent a while a while ago fixing a number of bugs around this,
and the current design intends for that to work as you describe.

The default quit handler passes the Ctrl-C to the target as long
as the terminal is not GDB's:

 void
 default_quit_handler (void)
 {
  if (check_quit_flag ())
    {
      if (target_terminal::is_ours ())
        quit ();
      else
        target_pass_ctrlc ();
    }
 }

... if the target is running and gdb wants to print
something, the terminal status should be target_terminal::ours_for_output(),
not target_terminal::ours().  With ours_for_output, input/Ctrl-C is still
forwarded to the target.

and then target_terminal::inferior() does:

  /* If the user hit C-c before, pretend that it was hit right
     here.  */
  if (check_quit_flag ())
    target_pass_ctrlc ();

and proceed(), called from all resumption commands, does this early:

  /* Since we've marked the inferior running, give it the terminal.  A
     QUIT/Ctrl-C from here on is forwarded to the target (which can
     still detect attempts to unblock a stuck connection with repeated
     Ctrl-C from within target_pass_ctrlc).  */
  target_terminal::inferior ();


So a source of bugs would be something calling "target_terminal::ours ()"
when it shouldn't.  There's a "target_terminal::ours ()" call at the
end of windows_nat_target::attach that looks really wrong, for example.