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

[Anton Blanchard <antonb@tenstorrent.com>]

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