While trying to create a #define macro to programmatically generate a breakpoint on RISC-V using the cbreak instruction in the ISA, I noticed GDB halts execution as it should, but it doesn't allow stepping over it. This behaviour is unusual because on other architectures that have similar trap instructions, GDB allows the user to step over it. On mips I use "teq $0, $0"; POWER it's "twge %r2, %r2"; on x86 it's "int $0x03"; on arm64 it's "brk #0", etc. They all halt as they should, and then allow the user to step over the breakpoint.
RISC-V doesn't have a breakpoint instruction. ebreak is a generic trap instruction used for multiple purposes. The compiler uses it for program ending traps for instance. gdb does use ebreak, but gdb will only recognize an ebreak it emitted itself as an actual breakpoint. Any others are program ending traps. Note that the MIPS break instruction accepts an argument, and MIPS has defined one specific value to indicate a breakpoint. However, on RISC-V, ebreak does not take an argument, so we can't use that method to distinguish a program ending trap from a breakpoint. The semihosting spec uses ebreak, but it uses a specific sequence of instructions to indicate that this is a semihosting call and not a program ending trap. It does this because ebreak does not take an argument, and hence there is no other way to specify that this is a semihosting call. See https://github.com/riscv/riscv-semihosting-spec/blob/main/riscv-semihosting-spec.adoc#11-semihosting-trap-instruction-sequence Because an ebreak instruction is ambiguous, I'm concerned that it would be dangerous to let the debugger step over it by default. We could maybe add an option to allow someone to step over ebreak if they really want to, and leave it off by default. Or we could define a sequence of instructions that is meant to be a user breakpoint like was done for the semihosting spec, and then teach gdb to respect that. Or maybe it is normal for gdb to let users step over a trap instruction, even though program state may be undefined at that point?
Hey Jim, Sorry, there was a typo in my original post. I meant ebreak, not cbreak. I tried the semihosting trap instruction sequence and I still had the same result on the ebreak instruction: asm volatile("slli x0, x0, 0x1f; ebreak; srai x0, x0, 7"); While folks figure out whether this is a bug in GDB or intentional, do you have a suggested workaround for what I'm trying to achieve? I'm aware of the kill() and raise() functions, but they require an #include, whereas inline asm rolled into a #define macro does not.
On IRC, Jessica Clarke suggested that gcc could use unimp for a program ending trap, thus leaving ebreak for user breakpoints. I think we are already using unimp for something else (padding bytes in text?), but that probably doesn't conflict with the new proposed use.
The problem with using an unimp (non-)instruction is it creates a SIGILL when the intention is to try and create a bona fide SIGTRAP. Something I found interesting is I tried a little experiment on my RISC-V machine. If I use ::raise(SIGTRAP); it works as expected. But if I stepi through each instruction, no SIGTRAP exception is ever raised.