STEP_SKIPS_DELAY question, sort of

[Orjan Friberg <orjan.friberg@axis.com>]

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.)

--
Orjan Friberg
Axis Communications