This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: rs6000 / ppc backend in gdb
- From: Daniel Jacobowitz <drow at false dot org>
- To: Stefan Burström <f94sbu at efd dot lth dot se>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 1 Aug 2005 09:12:03 -0400
- Subject: Re: rs6000 / ppc backend in gdb
- References: <20050731011738.GA13782@nevyn.them.org> <33e11968721.41b5c8f4@mail.m.bonet.se>
On Sun, Jul 31, 2005 at 11:02:36PM +0100, Stefan Burström wrote:
> Clearly, this is a limitation in the ppc backend of gdb. I have reached as
> far as I understand that the skip_prologue function is responsible for
> figuring out the stack frame of the function. However, why is this needed?
> How come gdb does all this? Isn't the position of lr and prev_sp well
> defined in the stack frame?
No, absolutely they aren't! We've learned, over years of debugging
people's real code, that trusting the architecture defined stack layout
is not a good choice. For instance, on x86 -fomit-frame-pointer is
popular to free up an additional register.
You weren't very specific about what versions you were testing, but on
x86 you've probably got DWARF2 CFI available, which allows reliable
unwinding without prologue analysis. On PPC we don't support DWARF2
CFI yet; until recently, GCC wrote out buggered CFI in which LR and
another register had the same register number. That's been fixed, but
to turn on PPC CFI support we'd need to detect and work around it, and
no one's implemented that yet.
--
Daniel Jacobowitz
CodeSourcery, LLC