Re: Breakpoints in delay slots

[Andrew STUBBS <andrew.stubbs@st.com>]

Mark Kettenis wrote:
> This is because the SH4 can have "data words" in the instruction
> stream isn't it?

No, not if you are saying what I think you are saying, but there can be 
data very close to the instructions. It can occur immediately before a 
function (I don't know that the compiler does this, but hand written 
assembler might), or, due to the small range of offsets available, there 
may be a constant pool within the body of the function which the code 
branches past.

> As Daniel already mentioned this does sound pretty similar to what

I haven't seen anything from Daniel???? I have found it on the web 
archive now though.

> 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().

How does one fix the problem that GDB doesn't associate the trap with 
the breakpoint? Not only will it tell the user there was an unexpected 
trap, ignore any conditions or commands, and show the source location as 
somewhere else, but it won't take any measures to avoid the breakpoint 
on the restart.

Thanks

Andrew