public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: "Stefan Burström" <f94sbu@efd.lth.se>
Cc: gdb@sources.redhat.com
Subject: Re: rs6000 / ppc backend in gdb
Date: Mon, 01 Aug 2005 13:12:00 -0000	[thread overview]
Message-ID: <20050801131203.GA4405@nevyn.them.org> (raw)
In-Reply-To: <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

  reply	other threads:[~2005-08-01 13:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-28  0:50 PPC stack trace Stefan Burström
2005-07-31  0:19 ` rs6000 / ppc backend in gdb Stefan Burström
2005-07-31  1:17   ` Daniel Jacobowitz
2005-07-31 22:15     ` Stefan Burström
2005-08-01 13:12       ` Daniel Jacobowitz [this message]
2005-08-01 20:45         ` Stefan Burström
2005-08-01 20:51           ` Daniel Jacobowitz
2005-08-01 21:08             ` Stefan Burström

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050801131203.GA4405@nevyn.them.org \
    --to=drow@false.org \
    --cc=f94sbu@efd.lth.se \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).