Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

[Randolph Chung <randolph@tausq.org>]

> I'm wondering about:
> 
> # 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

I was too, but actually this seems to do something slightly different.

single_step_through_delay seems to be asking: "does the current
instruction have a delay slot"? This is used to tell gdb that if we
wanted to do a step on a branch-insn-with-a-delay-slot, then after we
step through the branch insn, we will step one more insn.

Is that correct?

The comment is confusing because it talks about "executing a delay slot"
but at least mips-tdep.c, the only implementation of this method,
doesn't test that. It tests "executing a branch insn with a delay slot".

The new method i'm adding is a bit different though. The PA has a
concept of "nullified" instructions. Based on the result of a previous
instruction (which may or may not be a branch insn), the next
instruction may be nullified. This is in many ways the precursor to the
highly predicated insn model of IA64. By examining the insn at pc (or
previous pc) you cannot tell whether the current insn is nullified. You
can only tell that by examining processor flags. (Possibly on ia64 you
would extract the predicate register from the current insn and examine
the contents of that predicate register. I haven't looked at the
details.)

> I suspect that at one stage it was behaving like 
> single_step_through_delay, but was then changed to perform the same 
> operation unconditionally (i.e., when stopping from a cntrl-c say).  GDB 
> trying to helpfully do a few extra steps after a cntrl-c bugs me :-)

i was trying to figure out that piece of commented out code too and why
it was changed. looked through cvs history but didn't find it. I'm not
particularly fond of introducing new almost-arch-specific gdbarch
methods either, but this does seem to be doing slightly different things
than the existing ones. OTOH this is almost a "cosmetic" feature, so one
alternative is to drop the INSTRUCTION_NULLIFIED logic completely....

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