Re: mips-tdep.c: Adjust breakpoints in branch delay slots

["Maciej W. Rozycki" <macro@mips.com>]

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