Breakpoints in delay slots
Andrew STUBBS
andrew.stubbs@st.com
Fri Oct 20 08:42:00 GMT 2006
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
More information about the Gdb
mailing list