This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Breakpoints in delay slots
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb at sourceware dot org
- Date: Wed, 18 Oct 2006 10:03:53 -0400
- Subject: Re: Breakpoints in delay slots
- References: <453608FC.2040201@st.com>
On Wed, Oct 18, 2006 at 11:59:08AM +0100, Andrew STUBBS wrote:
> Hi all,
>
> There is an occasional issue debugging programs on processors that use
> delay slots - in my case the SH4.
>
> 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.
>
> In the case of the SH4, the breakpoint instruction (at least the one we
> use) is illegal in a delay slot. This means that, instead of triggering
> the breakpoint, an illegal slot exception is raised which the user
> program is expected to handle and usually results in a panic.
>
> In any case, even if the breakpoint were handled as normal, there is the
> problem of where the program should be resumed. It is incorrect to set
> the PC to the slot instruction because this will ignore the branch. The
> correct thing is to set the PC to the address of the branch/slot pair -
> i.e. 2 bytes back in the case of the SH4.
>
> There is no general way to identify a delay slot from instruction
> analysis - any instruction may be preceded by data which looks like a
> branch with a slot, and there is the danger of reading addresses outside
> memory - so there is no way to avoid the situation in the first place.
> Similarly, there is no way to identify that a breakpoint just hit was in
> a slot unless you make a note of how it was hit.
>
> I need a way to solve this problem. Any suggestions?
This is a remarkable mess. Unsurprisingly you aren't the first person
to have this sort of problem, so GDB has a certain amount of support
for delay slots, but MIPS at least is much friendlier: you can use the
same breakpoint instruction, and there's a bit in the cause register
that lets you know you were in a delay slot.
When you have a symbol file, does that suffice to let you know what
is code and what is data?
--
Daniel Jacobowitz
CodeSourcery