This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Breakpoints in delay slots


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]