riscv-openocd
riscv-openocd copied to clipboard
riscv
Fixed halt reason after single-step
After single step operation, we should not assume that the halt reason is single-step. There can be a higher-priority halt cause, e.g. a breakpoint.
The real halt reason should be obtained from the target (dcsr.cause).
What testing have you done for this?
I've tested this internally against the LLDB debugger (which speaks the GDB Remote protocol, same as GDB). Without the patch, the debugger did not report a watchpoint hit during single-stepping to the user.
For GDB, I need to run riscv-tests/debug, after I resolve some locally occurring riscv-test issues mentioned in https://github.com/riscv/riscv-openocd/pull/563.
Assuming e.g. all the spike32-2 tests from riscv-tests/debug pass then I'm fine merging this.
Assuming e.g. all the spike32-2 tests from riscv-tests/debug pass then I'm fine merging this.
I've run the riscv-tests on this change here: https://github.com/JanMatCodasip/riscv-openocd/pull/3 It turns out the impact of this change is large and many tests now fail. I am parking this change (draft) until I manage to find the cause and fix it.
I still believe reporting the real halt cause to the debugger when stepping is correct approach, yet this change is not sufficient as is and something else needs to be updated as well.
Closing this outdated merge request.
The main problem appears to be that riscv_openocd_step() reports resume + halt to GDB every time, but "internal" steps (e.g. when resuming from a trigger) should be hidden from the GDB. This can be fixed in a separate merge request.