This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: STEP_SKIPS_DELAY question, sort of
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 24 May 2004 11:15:07 +0200
- Subject: Re: STEP_SKIPS_DELAY question, sort of
- Organization: Axis Communications
- References: <40AE38D0.7010204@axis.com> <40AE659A.90207@gnu.org>
Andrew Cagney wrote:
Earlier MIPS variants (at least) needed STEP_SKIPS_DELAY. When at
``0x0'', a hardware single-step would end up at ``foo''. That isn't
your problem.
Since your hardware can single-step into a delay slot, can it also
resume from the delay slot? An example of this is SPARC with its
constantly shuffling PC/N[ext]PC -- the inferior is resumed with PC==0x2
N[ext]PC==foo.
I'm not sure I understand what you mean by "can resume" - it can resume
from a delay slot, but when doing so the branch instruction (and the
delay slot) is re-executed. I don't have an NPC, and AFAIK there's no
information in the CPU registers that tells me whether the branch is
taken or not (which seems consistent with the fact that the
branch-instruction is re-executed).
Maybe this can be stated in even simpler terms than "don't re-insert a
breakpoint on an instruction that's going to be restarted when we resume
execution". Rather, "single-step twice before re-inserting a breakpoint
we're currently stopped at".
--
Orjan Friberg
Axis Communications