Re: MIPS saved register troubles

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Jan 26, 2004 at 12:07:08PM -0500, Andrew Cagney wrote:
> >I spent some time fiddling with backtraces in an o32 application, using a
> >mips64-linux GDB, this morning.  They don't work so well :)  The basic
> >problem is the [0,NUM_REGS) hack.  mips_register_raw_size reports that
> >register $28 is 8 bytes wide, so legacy_saved_regs_prev_register loads two
> >consecutive saved values into $28, and it looks like 0x7ffffe007ffffd8c 
> >($s8
> >concatenated with $sp).
> 
> Can you provide more details?

Sure.  It turns out I was mistaken about [0,NUM_REGS) being directly
the problem - we were actually unwinding in [NUM_REGS, NUM_REGS * 2).

What happens is that legacy_saved_regs_prev_register copies
REGISTER_RAW_SIZE(regno) bytes from memory into the register cache. 
When debugging an o32 binary with a mips64-configured GDB,
REGISTER_RAW_SIZE(90 + 28) is 8.  But a normal o32 stack frame pushes 4
bytes per register.  So the eight-byte copy gets this saved register
and the next one also.

> >Fixing this is going to be ugly.  Andrew, I don't suppose you have a plan 
> >to
> >migrate MIPS to the new frame code, thereby making all this go away?
> 
> I'm not so sure?  BTW, you can't miss my irregular MIPS cleanups.  My 
> current problem is:
> [regression] Internal error: pc 0x400b21 in read in psymtab, but not in 
> symtab.
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1519
> look familar?

Not at all.  Pertinent missing detail - does this show up with HEAD? 
Or is HEAD broken for some other reason?

I don't have an IRIX system but I can probably get a sense of the
problem on mips64-linux.  I'll take a look this week.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer