Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

[Mark Kettenis <kettenis@gnu.org>]

   Date: Thu, 18 Nov 2004 08:21:08 -0800
   From: 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?

I think the description is misleading.

   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 problem on MIPS is that if you trap on a delay slot, the processor
backs up the PC to the preceding branch instruction.  As a result,
naively single-stepping will re-execute the branch instruction again
and again.  Therefore, operating systems and GDB's software
single-stepping machinery will step over the delay slot, effectively
executing two instructions in a row instead of one.  Now if there
would be a breakpoint-instruction in the delay slot, this won't work.
That's why we had the STEP_SKIPS_DELAY macro that makes sure the
single-step is done without any breakpoints inserted.  This was
replaced by single_step_through_delay which presumably will also be
used on a new CRISv32 port.

Another problem is when there is a breakpoint in the delay slot.
Hitting it would thoroughly confuse GDB since after hitting the
breakpoint instruction the PC will not point at the breakpoint, but at
the branch instruction.  Continuing from that point will hit the
breakpoint again and again.  I'm not sure the current code handles
this correctly.

   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....

Perhaps that isn't such a bad idea if it doesn't confuse GDB too much.

Mark