This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Breakpoints in delay slots
- From: Michael Snyder <Michael dot Snyder at palmsource dot com>
- To: Andrew STUBBS <andrew dot stubbs at st dot com>
- Cc: GDB List <gdb at sourceware dot org>
- Date: Wed, 18 Oct 2006 11:51:13 -0700
- Subject: Re: Breakpoints in delay slots
- References: <453608FC.2040201@st.com>
On Wed, 2006-10-18 at 11:59 +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
(1)
> this instruction happens to be the first instruction of a source line, or
(2)
> 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?
Sorry to be terse, but...
(1) -O0
(2) "Don't do that".
Michael