From mboxrd@z Thu Jan 1 00:00:00 1970 From: Orjan Friberg To: gdb-patches@sources.redhat.com Subject: STEP_SKIPS_DELAY question, sort of Date: Fri, 21 May 2004 17:14:00 -0000 Message-id: <40AE38D0.7010204@axis.com> X-SW-Source: 2004-05/msg00637.html 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