Re: Breakpoints in delay slots

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Wed, 18 Oct 2006 11:59:08 +0100
> From: Andrew STUBBS <andrew.stubbs@st.com>
> 
> 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. 

This is because the SH4 can have "data words" in the instruction
stream isn't it?

> 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?

As Daniel already mentioned this does sound pretty similar to what
MIPS does.  There is however an important difference in that MIPS will
actually generate a trap on the branch instruction and set a flag in a
register to indicate that the trap actually occured in the delay slot.

My solution would be to emulate what MIPS does.  So in the exception
handler for the illegal slot exception, check whether you've hit a
breakpoint.  If so report SIGTRAP back to GDB and make sure that if
you get a continue from GDB, you back up the instruction pointer to
the branch instruction preceding the delay slot.  This will require
you to implement sh_single_step_through_delay().

Incidentally we're currently porting OpenBSD to the SH4, and my
current plan for OpenBSD/sh is to do what I sketched above.

Mark