[PATCH v3 0/2] Fix gdb.base/sigstep.exp for riscv64-linux

[Pedro Alves]

Hi Jim,

On 2021-07-07 10:01 p.m., Jim Wilson wrote:
> On Tue, Jul 6, 2021 at 5:31 PM Lancelot SIX via Gdb-patches <
> gdb-patches@sourceware.org> wrote:
> 
>> This patch series fixes those errors.  Patch #1 disables tests that
>> cannot pass because the platform lacks support for hardware single
>> stepping.  Patch #2 implements stepping outside of signal handlers for
>> riscv*-*-linux* platforms.
>>
> 
> FYI On the HiFive Unleashed, it isn't possible to implement hardware
> breakpoints because the debug registers can only be accessed from debug
> mode, i.e. via jtag.  They can't be accessed by the linux kernel, so I only
> implemented software breakpoints.  The debug spec was later changed to
> allow a few debug registers to be accessed from machine mode, and this is
> implemented in the HiFive Unmatched.  So in theory we can support hardware
> breakpoints (and tracepoints) on the HiFive Unmatched and similar new
> targets, like the BeagleV.  This will require OpenSBI changes to add hooks
> to access the new registers, linux kernel changes to make the registers
> available, linux kernel changes to add new ptrace features to access them,
> and gdb changes to test for them and use them when available.  But
> unfortunately there is no one actively working on RISC-V Linux gdb support
> that I know of, so I have no idea when this work will be done.
> 
> When we do have hardware breakpoint support these tests will have to be
> re-enabled, though it will need to be conditional depending on whether the
> target under test supports hardware breakpoints or not.
> 


Note this is about hardware single-stepping, not hardware breakpoints.
In Linux/ptrace, this would mean the kernel would support PTRACE_SINGLESTEP.
The kernel would set some debug trace register flag on so that the CPU stops after
executing one instruction, and then report a SIGTRAP stop.