minichlink's "step" / "stepi" just hangs

[maxgerhardt]

Reproduction:

1. make in examples/blink (flashes successfully)
2. riscv-none-embed-gdb -ex "target remote :2000" blink.elf
3. b main
4. continue
5. step

Output:

riscv-none-embed-gdb -ex "target remote :2000" blink.elf
GNU gdb (xPack GNU RISC-V Embedded GCC, 64-bit) 8.3
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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=riscv-none-embed".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/sifive/freedom-tools/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from blink.elf...
Remote debugging using :2000
InterruptVectorDefault () at ../../ch32v003fun/ch32v003fun.c:968
968		return 1;
(gdb) b main
Breakpoint 1 at 0xa0: file ../../ch32v003fun/ch32v003fun.c, line 831.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at ../../ch32v003fun/ch32v003fun.c:831
831		RCC->CFGR0 = RCC_HPRE_DIV1 | RCC_PLLSRC_HSI_Mul2;      // PLLCLK = HSI * 2 = 48 MHz; HCLK = SYSCLK = APB1
(gdb) step

The last command hangs eternally. minichlink output shows no sign of errors.

$ ./minichlink -G
Found WCH Link
WCH Programmer is LinkE version 2.8
Chip Type: 003
Part Type (A): 0x0010 (This is the capacity code, in KB)
Part UUID    : ab-c8-ab-cd-13-de-bc-49
PFlags       : ff-ff-ff-ff
Part Type (B): 00-30-05-00
Interface Setup
GDBServer Running

Logs with set debug remote 1:

(gdb) step 
Sending packet: $m80,40#65...Ack
Packet received: 920100009401000096010000980100009a0100009c0100009e010000000000000290000000000000000000000000000000000000000000000000000000000000
Sending packet: $Z1,a0,2#a6...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: OK

It seems to wait for more packets after the last one? Maybe some "event" packet or the state of the registers or something?

[maxgerhardt]

Most interestingly it doesn't seem to hangup when I only forward the code execution with break main.c:55 continue commands. But I really can't have users do that manually, the "step" should work.

[cnlohr]

This has been an absolute doozie.

I specifically do not include s in the vCont reply, telling it I don't support s. It appears that some versions of GDB respect this, others do not.

I'm currently testing with version 12, which reliably recreates the error. And it was a little complicated but it seems to be working very reliably now.