I'm facing a problem with the CRIS target which is related to what STEP_SKIPS_DELAY is aiming to solve,. The problem occurs when single-stepping past a breakpoint set on an instruction with a delay slot, because execution resumes at the instruction *preceding* the delay slot. Here's an illustration of what happens:
0x0 ba foo (branch instruction)
0x2 nop (delay slot)
If there's a breakpoint (implemented in CRIS with a "break" instruction) at address 0x0, the following happens when single-stepping (hardware assisted):
(1) We end up in the delay slot at address 0x2.
(2) GDB re-inserts the break instruction at address 0x0.
(3) Execution resumes at address 0x0, and we hit the breakpoint again.
Besides STEP_SKIPS_DELAY having a fixed offset of 4 bytes between instruction and its associated delay slot, it's concerned with a breakpoint being set in the delay slot, which isn't the case here.
Basically, what I'm looking for is a way to say "don't re-insert a breakpoint on an instruction that's going to be restarted when we resume execution". I'm thinking other architectures have faced similar issues, but I couldn't find anything.
(The alternatives I could think of are (1) fudging the address we report as being stopped at, to trick GDB into stepping one more time before re-insterting the breakpoint, or (2) automatically single-step past the delay slot (without reporting to GDB), both of which may be confusing for a user.)