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


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


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