This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED
- From: Randolph Chung <randolph at tausq dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 30 Nov 2004 22:19:24 -0800
- Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED
- References: <20041118000159.GG15714@tausq.org> <419CB118.7080401@gnu.org> <20041118162108.GK15714@tausq.org> <200411181655.iAIGthDa026050@juw15.nfra.nl> <20041123174937.GL9148@tausq.org> <41AA09F8.4020006@gnu.org> <20041128184141.GG6359@tausq.org> <41AA2D08.3030304@gnu.org> <20041129033013.GJ6359@tausq.org> <41AB3C1D.80509@gnu.org>
- Reply-to: Randolph Chung <randolph at tausq dot 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/