This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Breakpoints in delay slots
> Date: Fri, 20 Oct 2006 09:42:33 +0100
> From: Andrew STUBBS <andrew.stubbs@st.com>
>
> > 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.
Ah, looks like I wasn't quite clear about this. You'll have your stub
(or OS kernel) report the address of the delay slot as where it
stopped (such that gdb will do the right thing for hitting the
breakpoint). But the stub will remember that it actually hit a
breakpoint in a delay slot. Later when gdb asks the stub to continue,
you make it back up to the address of the branch instruction before
you let it run again.
Mark