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: Daniel Jacobowitz <drow at false dot org>
- To: "Maciej W. Rozycki" <macro at mips dot com>
- 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, 25 May 2007 09:19:11 -0400
- 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>
On Fri, May 25, 2007 at 01:21:57PM +0100, Maciej W. Rozycki wrote:
> On Fri, 25 May 2007, Maciej W. Rozycki wrote:
>
> > In principle on bare iron it should be doable, but the problem is, IIRC,
> > the state of cp0.cause.bd is not propagated under Linux to userland in any
> > way. And at the moment I'm not sure how this would affect EJTAG debugging
> > either.
>
> 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.
Great. Want to take a look at doing this the other way then?
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.
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).
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.
--
Daniel Jacobowitz
CodeSourcery