This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
STEP_SKIPS_DELAY question, sort of
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 21 May 2004 19:13:59 +0200
- Subject: STEP_SKIPS_DELAY question, sort of
- Organization: Axis Communications
I'm facing a problem with the CRIS target which is related to what
STEP_SKIPS_DELAY is aiming to solve,. The problem occurs when
single-stepping past a breakpoint set on an instruction with a delay
slot, because execution resumes at the instruction *preceding* the delay
slot. Here's an illustration of what happens:
0x0 ba foo (branch instruction)
0x2 nop (delay slot)
If there's a breakpoint (implemented in CRIS with a "break" instruction)
at address 0x0, the following happens when single-stepping (hardware
assisted):
(1) We end up in the delay slot at address 0x2.
(2) GDB re-inserts the break instruction at address 0x0.
(3) Execution resumes at address 0x0, and we hit the breakpoint again.
Besides STEP_SKIPS_DELAY having a fixed offset of 4 bytes between
instruction and its associated delay slot, it's concerned with a
breakpoint being set in the delay slot, which isn't the case here.
Basically, what I'm looking for is a way to say "don't re-insert a
breakpoint on an instruction that's going to be restarted when we resume
execution". I'm thinking other architectures have faced similar issues,
but I couldn't find anything.
(The alternatives I could think of are (1) fudging the address we report
as being stopped at, to trick GDB into stepping one more time before
re-insterting the breakpoint, or (2) automatically single-step past the
delay slot (without reporting to GDB), both of which may be confusing
for a user.)
--
Orjan Friberg
Axis Communications