[PATCH] RISC-V: Use hardware single step when available

[PATCH] RISC-V: Use hardware single step when available

[Anton Blanchard]

If the target supports hardware single-stepping use it instead of
inserting software breakpoints. We continue to use software breakpoints
for stepping over LR/SC atomic sequences.
---
 gdb/riscv-tdep.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c
index 100a44cddf3..0413d7b1a35 100644
--- a/gdb/riscv-tdep.c
+++ b/gdb/riscv-tdep.c
@@ -4707,6 +4707,11 @@ riscv_software_single_step (struct regcache *regcache)
   if (!next_pcs.empty ())
     return next_pcs;
 
+  /* If the target supports hardware single-stepping, software
+     single-stepping is unnecessary.  */
+  if (target_can_do_single_step ())
+    return {};
+
   next_pc = riscv_next_pc (regcache, cur_pc);
 
   return {next_pc};
-- 
2.34.1

Re: [PATCH] RISC-V: Use hardware single step when available

[Tom Tromey]

>>>>> "Anton" == Anton Blanchard <antonb@tenstorrent.com> writes:

Anton> If the target supports hardware single-stepping use it instead of
Anton> inserting software breakpoints. We continue to use software breakpoints
Anton> for stepping over LR/SC atomic sequences.

I'm definitely not the person to review RISC-V bugs.

That said, I'm curious about two things.

First, if the target advertises that it can single-step, should that
include stepping over atomic sequences?  IOW could this also be deferred
to, say, gdbserver to handle properly?

Second, I wonder why target_can_do_single_step isn't called at some
higher level.

Anyway I see that arm-linux-tdep.c -- but not arm-tdep.c,
mysteriously -- does what you've done here.  And I don't have any
objection or anything, just questions.

Tom

Re: [EXT] Re: [PATCH] RISC-V: Use hardware single step when available

[Anton Blanchard]

Hi Tom,

On Thu, Sep 17, 2026 at 1:04 AM Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "Anton" == Anton Blanchard <antonb@tenstorrent.com> writes:
>
> Anton> If the target supports hardware single-stepping use it instead of
> Anton> inserting software breakpoints. We continue to use software breakpoints
> Anton> for stepping over LR/SC atomic sequences.
>
> I'm definitely not the person to review RISC-V bugs.
>
> That said, I'm curious about two things.
>
> First, if the target advertises that it can single-step, should that
> include stepping over atomic sequences?  IOW could this also be deferred
> to, say, gdbserver to handle properly?

The problem is that we have multiple types of targets that support
hardware single-stepping. Simulators (eg QEMU) can single-step through
an lr/sc sequence, but in-band single stepping (eg via ptrace) and
some hardware debuggers cannot because the reservation clears on an
exception. I chose the most conservative option (similar to ARM), but
Nick Piggin let me know about this patch where he exposes an option to
configure it:

https://sourceware.org/pipermail/gdb/2024-February/051080.html

He also suggested adding a qSupported flag to automatically configure
this, which QEMU can set.

Thanks,
Anton

> Second, I wonder why target_can_do_single_step isn't called at some
> higher level.
>
> Anyway I see that arm-linux-tdep.c -- but not arm-tdep.c,
> mysteriously -- does what you've done here.  And I don't have any
> objection or anything, just questions.
>
> Tom