Re: Breakpoints in delay slots

[Michael Snyder <Michael dot Snyder at palmsource dot 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