Re: Breakpoints in delay slots

[Jim Blandy <jimb@codesourcery.com>]

Andrew STUBBS <andrew.stubbs@st.com> writes:
> The problem occurs when a breakpoint is placed on the delay slot
> instruction. This can happen when this instruction happens to be the
> first instruction of a source line, or when the user sets the
> breakpoint on a specific address.

Yeah.  As others have said, this is a pain.

The important thing to note here is that there's a bit of processor
state that I gather you don't have access to on the SH4 --- the 'next
PC', to which control will go after the current instruction.  If the
SH4 doesn't provide GDB enough information to predict where
non-exceptional flow should go on resumption, or if it exists but the
kernel doesn't make it available to GDB, then that's the fundamental
bug.

The SPARC (or am I thinking of the HPPA?) actually makes this
explicit, with an NPC ("next pc") register.  In a delay slot, PC will
point at the instruction in the delay slot, and NPC points to the
target of the branch.

MIPS effectively provides the same information with the bit in the
cause register.