Re: [PATCH v2 15/16] GNU/Linux: Interrupt/Ctrl-C with SIGSTOP instead of SIGINT [PR gdb/9425, PR gdb/14559]

[Pedro Alves <pedro@palves.net>]

Hi Maciej,

On 2021-07-09 12:05 a.m., Maciej W. Rozycki wrote:
> On Mon, 14 Jun 2021, Pedro Alves wrote:
> 
>> This commit has a user-visible behavior change in all-stop mode --
>> when you interrupt the program with Ctrl-C, instead of:
>>
>>   Thread 1 "threads" received signal SIGINT, Interrupt.
>>
>> You'll get:
>>
>>   Thread 1 "threads" stopped.
>>
>> Which is what you already got with the "interrupt" command in non-stop
>> mode.
>>
>> If you really want to pass a SIGINT to the program, you can then issue:
>>
>>   (gdb) signal SIGINT
> 
>  Can you still do:
> 
> (gdb) handle SIGINT nostop noprint noignore
> 
> instead to make SIGINT go through to the debuggee right away without GDB
> getting bothered in any way?  I've had a need to use such a setup numerous
> times (normally you can still hit ^Z or ^\ to get GDB interrupted with
> SIGTSTP or SIGQUIT respectively instead).
> 

Yes, in the sense that if a SIGINT it sent to the inferior, it will go
through to the debuggee right away.  However, if you press Ctrl-C in
GDB (which is probably what you're asking), then it will stop the
program regardless of "handle SIGINT".  I've been thinking that to handle
scenarios like these and Eli's emacs scenario, GDB could gain some
command to configure it's own interrupt key.  The inferior's
terminal would still inherit the terminal settings that GDB had when it
was started up, so the terminal's interrupt key as configured when GDB
started (usually ^c) would still raise a SIGINT in the inferior.    So in
your scenario you'd do "set interrupt-key ^g" or some such, like:

 (gdb) handle SIGINT nostop noprint noignore
 (gdb) set interrupt-key ^g

With the above, ctrl-c would result in a SIGINT in the inferior
and ctrl-g would always stop the program, no matter what the program
does with signal masks/dispositions.