This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MIPS saved register troubles


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]