'interrupt' command usecase in all-stop mode.

[Muhammad Bilal]

Hi,

On 8/12/20 11:16 PM, Pedro Alves wrote:
>
>> 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.
>
CDT needs MI record for stop reason but there are some usecases where 
GDB does not emit MI record in a reply of SIGINT signal and hence CDT 
hang or faded suspend icon.

For example use dprintf in debugging.

test.c

#1 #include <stdio.h>
#2
#3 int main ()
#4 {
#5    while(1)
#6        printf ("hello world\n");
#7   return 0;
#8 }

$ gcc -g3 -o hello hello.c

$ gdbserver :10000 ./hello
Process ./hello created; pid = 254077
Listening on port 10000

$ gdb -q ./hello
Reading symbols from ./hello...
(gdb) set dprintf-style call
(gdb) dprintf 6, "print dprintf\n"
Dprintf 1 at 0x1151: file /var/mentor/hello.c, line 6.
(gdb) set debug remote 1
(gdb) set pagination off
(gdb) tar rem :10000
(gdb) c

Give Ctrl-C signal

Sending packet: $Z0,555555555151,1#87...Packet received: OK
Sending packet: $Z0,7ffff7dfbe10,1#0b...Packet received: OK
Sending packet: $Z0,7ffff7dfbf21,1#0e...Packet received: OK
Sending packet: $Z0,7ffff7dfbfb7,1#44...Packet received: OK
Sending packet: $Z0,7ffff7ee8a51,1#e2...Packet received: OK
Sending packet: $Z0,7ffff7fd37a5,1#e3...Packet received:^C[1285 bytes 
omitted]...Packet received: OK
Quit
(gdb)

You can see at this point GDB just call QUIT macro and if there is mi 
interpreter then it does not emit any MI record.


Second use case is more critical where GDB even miss the ^C and target 
is not stopped.

Launch qemu system with semihosting

$ ./qemu-system-arm -S -gdb tcp::10000 --semihosting --serial null 
--monitor null -kernel /dev/null -M sabrelite


$ ./arm-none-eabi-gdb -q hello
Reading symbols from /var/mentor/hello...
(gdb) set debug remote 1
(gdb) load
(gdb) tar rem :10000
(gdb) c

Give Ctrl-C .

But gdb will not handle this Ctrl-C

Below is specific log for this. You can see ^C character at line #6 .

Sending packet: $m903c18,c#64...Ack
Packet received: 68656c6c6f20776f726c640a
hello world
Sending packet: $Fc#a9...Ack
Packet received: Fwrite,00000001,00903c18,0000000c
Sending packet: $m903c18,c#64^C...Ack
Packet received: 68656c6c6f20776f726c640a
Sending packet: $F-1,4#04...Ack
Packet received: Fwrite,00000001,00903c18,0000000c
Sending packet: $m903c18,c#64...Ack
Packet received: 68656c6c6f20776f726c640a

At this point CDT will again hang.


Above are still some problems with Ctrl-C signal, whereas these are not 
observed with 'target-asyn+interrupt' commands


Thanks,

-Bilal