Re: STEP_SKIPS_DELAY question, sort of

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

Andrew Cagney wrote:
I think there is still some missing information.  Given:
  N+0: branch foo
  N+2: nop
and PC==N+0, exactly what state information is available after doing a 
single hardware single-step (PC and status registers)?
State information is only PC (see below) and SPC (single-step PC). 
There's no information in the status registers regarding branch 
taken/not taken.

(The h/w single-step procedure works like this: after the instruction 
pointed out by the SPC has been executed, a single-step exception is 
given, and the SPC is updated to the next instruction.)

- If I understand things correctly, one h/w single-step gets PC==N+2 and 
two h/w single-steps gets PC==foo.  For that to work there must be some 
additional state information lurking somewhere - a bit indicating 
stopped in delay slot perhaphs?
One h/w single-step actually gets PC==N+1, which I then adjust to N+2 
before reporting it to GDB.  So, (yes) the bit indicating stopped in a 
delay slot is the lowest bit of the PC.

- If there were a breakpoint at N+2, what state information would be 
available then.  If the breakpoint were then yanked, where would a 
single-step end up - again additional state information is needed to 
make this work?
With a breakpoint at N+2, PC==N+1 (again, interrupted in delay slot, 
will resume execution at N) and PC is reported as N+2.  For a 
single-step at this point, SPC is set up with N+2, so a single-step 
exception fires after the delay slot has been executed.

(The decrementation of the PC when executing a break instruction is 
handled by the stub itself, which becomes a bit of a kludge when we're 
stopped in a delay slot.)

What could be implemented relatively easily is to automatically 
single-step again if we end up in a delay-slot due to a single-step (not 
due to a breakpoint though).  This would, in some sense, break the 
"stepi" command since we would step two instructions instead of one in 
those cases.

Maybe this can be stated in even simpler terms than "don't re-insert a 
breakpoint on an instruction that's going to be restarted when we 
resume execution".  Rather, "single-step twice before re-inserting a 
breakpoint we're currently stopped at". 


GDB needs to know that its in such a state.
Yeah, I had a look at resume/handle_inferior_event, and it certainly 
wasn't obvious to me how that kind of mechanism should be implemented.

--
Orjan Friberg
Axis Communications