Re: MIPS saved register troubles

[Andrew Cagney <cagney@gnu.org>]

> 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).

Ah, that explains why I wasn't so sure.

> 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.

If o32 on mips64, register 28 should be 8-bytes and register num_regs+28 
should be 4-bytes.   The latter being what the unwind code plays with. 
What does a backtrace look like?

>> >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?

That's how I found the bug :-)

> 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.

Per the bug report, can be reproduced using mips-elf-gdb.

I get the feeling that original patch should have modified the callers 
so that they supplied the section rather than have the function locally 
guess the section.  For MIPS, it's finding but then [incorrectly] 
discarding a valid absolute symbol.

Andrew