This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: mips-tdep.c: Adjust breakpoints in branch delay slots
- From: "Maciej W. Rozycki" <macro at mips dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sourceware dot org, Chris Dearman <chris at mips dot com>, "Maciej W. Rozycki" <macro at linux-mips dot org>
- Date: Fri, 15 Jun 2007 15:37:42 +0100 (BST)
- Subject: Re: mips-tdep.c: Adjust breakpoints in branch delay slots
- References: <Pine.LNX.4.61.0705241853450.21951@perivale.mips.com> <20070524183129.GA10094@caradoc.them.org> <Pine.LNX.4.61.0705251217190.13913@perivale.mips.com> <Pine.LNX.4.61.0705251318500.13913@perivale.mips.com> <20070525131910.GA28994@caradoc.them.org>
On Fri, 25 May 2007, Daniel Jacobowitz wrote:
> > FYI, I have now checked Linux and it should be fine -- must have been my
> > bad memory. EJTAG has provisions for handling this correctly
> > (cp0.debug.dbd), but I'm not sure if associated software gets it right.
EJTAG seems to be getting it right in principle -- there is one corner
case affecting us which I have identified, but it should be taken care of
elsewhere.
> Great. Want to take a look at doing this the other way then?
As much as I'd like to I may not be able to do it right now.
> The best option I can think of would be to fake the PC value based on
> the value of BD. You might be able to do this cleverly; have a
> register named "$pc" which shows the hardware contents of the PC
> register, and have read_pc / unwind_pc / write_pc adjust based on BD.
Note that there is nothing special needed for write_pc -- if you modify
the PC, you just write the new value to the "register" (there is actually
no such register as the PC in the MIPS architecture -- it's merely a
useful notion of "the next instruction to execute", which depending on the
way a debugger accesses the processor may happen to be recorded in various
cp0 registers).
BD is a merely a status bit which does not affect subsequent ERET/DERET.
> I'm not sure if that will work, but it does mimic the architecture
> behavior, which is an encouraging sign; and some other platforms do
> similar magic (e.g. HP/UX and IA64).
This is not rocket science -- the basic issue is to make gdb "accept" a
breakpoint that signals at a different address to one it was set at.
> It might be best to eliminate the setting of PC_REGNUM first, but
> that's multi-arch work; I see that dwarf2-frame.c relies on it unless
> you set dwarf2_frame_default_init_reg.
I am not sure what you mean here...
Maciej