[patch/RFA] multiarch INSTRUCTION_NULLIFIED
Randolph Chung
randolph@tausq.org
Wed Dec 1 06:19:00 GMT 2004
> >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/
More information about the Gdb-patches
mailing list