How to support interrupting a single step

How to support interrupting a single step

[Torsten Robitzki]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

Hi,
I’m writing a debug server to support the debugging of an ARM Cortex M4 (nRF52) controller via SWD (Bluetooth LE debugger). I have a test program that contains an endless loop (loops over a systick counter with masked PendSV, SysTick interrupts [C_MASKINTS]). If I run that program (‚c‘ package) and interrupt the execution by ctrl-C (0x03) and try to single step through the program, I can’t get back onto the GDB prompt by cntr-C as I would expect.

I can see that GDB is sending sequences of ’s’ and ‚g‘ packages and from the content of the ‚g‘ I can see, that the $PC is moving. When I press ctrl-C, I can see that GDB is sending interrupts (0x03) to my debug stub, but as both, ’s’ and ‚g‘ are short running commands, there is no point in making them aware of an interrupt. Even if I would, I could tell, what the correct return values would be to make GDB stop sending `s` and `g` packages.

Any idea, on how to make „step“ in this scenario interruptable?

best regards,

Torsten

--
Torrox GmbH & Co. KG
persönlich haftender Gesellschafter: Torrox Verwaltungs GmbH, Rehau (Amtsgericht Hof, HRB 5927)
Geschäftsleitung:                    Dipl.-Ing. Torsten Robitzki
Umsatzsteuer-Identifikationsnr.:     DE253527398
Adresse:                             Fabrikstraße. 22; 95111 Rehau
Handelsregistereintrag:              Amtsgericht Hof, HRA 4650
Telefon:                             +49 9283 8999666






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: How to support interrupting a single step

[Luis Machado]

Hi,

On 9/4/19 12:24 PM, Torsten Robitzki wrote:
> Hi,
> I’m writing a debug server to support the debugging of an ARM Cortex M4 (nRF52) controller via SWD (Bluetooth LE debugger). I have a test program that contains an endless loop (loops over a systick counter with masked PendSV, SysTick interrupts [C_MASKINTS]). If I run that program (‚c‘ package) and interrupt the execution by ctrl-C (0x03) and try to single step through the program, I can’t get back onto the GDB prompt by cntr-C as I would expect.
> 
> I can see that GDB is sending sequences of ’s’ and ‚g‘ packages and from the content of the ‚g‘ I can see, that the $PC is moving. When I press ctrl-C, I can see that GDB is sending interrupts (0x03) to my debug stub, but as both, ’s’ and ‚g‘ are short running commands, there is no point in making them aware of an interrupt. Even if I would, I could tell, what the correct return values would be to make GDB stop sending `s` and `g` packages.

The behavior of GDB when dealing with a tight/endless loop is known. See 
https://sourceware.org/bugzilla/show_bug.cgi?id=21221.

The problem of GDB sending lots of 's' and 'g' packets is also known, 
but i thought it had been fixed a while ago. We tried to harden that 
mechanism a bit more.

Are you running an older GDB version by any chance? If not, it may be a 
good idea to file a ticket so we can take a look at it.

> 
> Any idea, on how to make „step“ in this scenario interruptable?
> 

It should already be interruptible, but the timing and speed of 
communications between GDB and the debug server tends to cause problems.

Re: How to support interrupting a single step

[Torsten]

[-- Attachment #1: Type: text/plain, Size: 3146 bytes --]

Hi Luis,

I’m sorry, for the very late reply!

> Am 18.10.2019 um 15:08 schrieb Luis Machado <luis.machado@linaro.org>:
> 
> 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.

> The problem of GDB sending lots of 's' and 'g' packets is also known, but i thought it had been fixed a while ago. We tried to harden that mechanism a bit more.
> 
> Are you running an older GDB version by any chance? If not, it may be a good idea to file a ticket so we can take a look at it.

$ arm-none-eabi-gdb -v
GNU gdb (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.0.20190703-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

> It should already be interruptible, but the timing and speed of communications between GDB and the debug server tends to cause problems.

Wouldn’t it be enough, if GDB just stops to execute these ’s’, ‚g‘ package sequences? If not, what do I have to implement on the debug server side, to let my interrupt such a situation?

best regards,

Torsten

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: How to support interrupting a single step

[Luis Machado]

On 3/27/20 2:15 PM, Torsten@Robitzki.de wrote:
> Hi Luis,
> 
> I’m sorry, for the very late reply!
> 
>> Am 18.10.2019 um 15:08 schrieb Luis Machado <luis.machado@linaro.org>:
>>
>> 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.

Re: How to support interrupting a single step

[Torsten]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

Hi Luis,

> Am 27.03.2020 um 19:27 schrieb Luis Machado <luis.machado@linaro.org>:
> 
> 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.

perfect, that solves the problem. Thank you very much!

best regards,

Torsten

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: How to support interrupting a single step

[Luis Machado]

On 3/30/20 6:15 AM, Torsten@Robitzki.de wrote:
> Hi Luis,
> 
>> Am 27.03.2020 um 19:27 schrieb Luis Machado <luis.machado@linaro.org>:
>>
>> 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.
> 
> perfect, that solves the problem. Thank you very much!

Great! You're welcome.