Re: How to support interrupting a single step

On 3/27/20 2:15 PM, [email protected] wrote:
> Hi Luis,
> 
> I’m sorry, for the very late reply!
> 
>> Am 18.10.2019 um 15:08 schrieb Luis Machado <[email protected]>:
>>
>> The behavior of GDB when dealing with a tight/endless loop is known. See https://sourceware.org/bugzilla/show_bug.cgi?id=21221.
> 
> that Bug describes behavior, that a tide loops can’t be jumped over. In my case, I try to interrupt that scenario. So running the binary, till that loop. Interrupt execution and finding the program counter in that loop. Then single stepping over the loop (either ’s’ or ’n’). Then gdb does not break on the next execution of the loop and I’m unable to break into the debugger again. ctrl-c simply does nothing and I have to kill the debug server, so that the lost connection to the debug server gives me the prompt back.
> 
> Debugging the packages send and received, I find following:
> 
> ^C
> 
> 00d0030020276f0200b86a0200008c0021d0030020000000000000000000000000000000000000000000000000
> remote_pass_ctrlc called
> remote_interrupt called
> Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD;
> Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200ba6a020000980021d0030020000000000000000000000000000000000000000000000000
> Sending packet: $s#73...^Cremote_pass_ctrlc called
> remote_interrupt called
> Packet received: T05hwbreak;thread:0000DEAD;
> Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200bc6a020000000021d0030020000000000000000000000000000000000000000000000000
> Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD;
> Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200be6a020000000021d0030020000000000000000000000000000000000000000000000000
> 
> I would expect that once GDB recognizes, that I want to interrupt execution, it would stop sending ’s’ and ‚g‘ packages.
> 

GDB did recognize that you wanted to interrupt the remote and did send 
the right bytes to tell the remote to interrupt. I think what we're 
missing here is telling GDB your program stopped due to a SIGINT 
(GDB_SIGNAL_INT).

This is what i see when interrupting a remote on my local machine. 
Notice the signal sent is 02 and not 05 (SIGTRAP).


Sending packet: $vCont;s:p4e71.4e71;c:p4e71.-1#67...infrun: prepare_to_wait
remote_pass_ctrlc called
remote_interrupt called
Packet received: 
T0206:50e2ffffff7f0000;07:50e2ffffff7f0000;10:1046555555550000;thread:p4e71.4e71;core:1;
infrun: target_wait (-1.0.0, status) =
infrun:   20081.20081.0 [Thread 20081.20081],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_INT
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x555555554610
infrun: random signal (GDB_SIGNAL_INT)
infrun: stop_waiting
Sending packet: $z0,7ffff7a22c20,1#c3...Packet received: OK
Sending packet: $z0,7ffff7b18bc3,1#fc...Packet received: OK
Sending packet: $z0,7ffff7a22c93,1#cd...Packet received: OK
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: 
l<threads>\n<thread id="p4e71.4e71" core="1" name="loop"/>\n</threads>\n

Program received signal SIGINT, Interrupt.

So it seems your debugging stub needs to reply with SIGINT (interrupted) 
as opposed to SIGTRAP (meaning your program has concluded a single-step).

Let me know if that fix what you're seeing.