Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

[Randolph Chung <randolph@tausq.org>]

> >this is not possible to do in the general case though, because, sitting
> >on the current insn at pc, you cannot necessarily determine if the 
> >next insn will be nullified or not. (in the current example, the 
> >nullification is always applied, but it can be conditional on some 
> >computation being done)
> 
> I'm not sure what you mean.  What you describe sounds like the old 
> STEP_SKIPS_DELAY logic - a test on the _next_ instruction.  The new 
> logic instead:
> 
> # Return non-zero if the processor is executing a delay slot and a
> # further single-step is needed before the instruction finishes.
> M::int:single_step_through_delay:struct frame_info *frame:frame
> 
> checks to see if the _last_ instruction put us into a delay slot.

mmm... maybe i'm not reading the code correctly, but i still don't see 
how this will work for the hppa case.

this predicate is used in two places:

in proceed(), this only applies for the first insn at a "continue" or a
"step"/"next", right? so in any case it doesn't do anything if you are 
stepping through a series of instructions and the first one is not a 
branch/delay slot insn.

in handle_inferior_event(), the condition being checked is:

  if (stop_signal == TARGET_SIGNAL_TRAP
      && trap_expected
      && gdbarch_single_step_through_delay_p (current_gdbarch)
      && currently_stepping (ecs))

trap_expected will not be set when you are doing a "step" with single
stepping. possibly this works on mips because it uses software single
step? but on hppa we have hardware single step, and as far as i can tell
trap_expected is not set as we are stepping through instructions to get
to the next line when doing a "step". this condition again seems to be
more for the case when you hit a breakpoint at a branch insn with a
delay slot and you want to determine how to single step off that branch.
in the hppa case we have no breakpoints in this case.

i experimented with another proposal which is to adjust the pc when we
are at a nullified instruction. i modified target_read_pc () to return
the previous (or next) pc when we are at a nullified instruction. this 
fixes some of the failures but causes new failures with the 
"recurse.exp" test. i need to investigate that some more. but teaching 
target_read_pc() to lie about the current pc seems to be suboptimal.

lastly a comment about sparc -- i think the sparc case is simpler
because it doesn't have conditional nullification. so looking at a
particular insn you can always determine if the next insn will be
nullified or not. this is not always the case for hppa.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/