Re: STEP_SKIPS_DELAY question, sort of

[Orjan Friberg <orjan dot friberg at axis dot 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