From: Andrew Cagney <ac131313@redhat.com>
To: gdb@sources.redhat.com
Subject: GDB without traditional frames
Date: Thu, 25 Sep 2003 02:02:00 -0000 [thread overview]
Message-ID: <3F724CAE.3040502@redhat.com> (raw)
Hello,
As an accademic exercise I decided to see what would happen if a PPC64
GDB was configured to only use dwarf2 cfi (just disable the trad-frame
code).
The short answer is "it works (mostly)".
The long answer is ...
It relies on there being 100% coverage of the CFI. System libraries can
sometimes be lacking. Assembler stubs, for instance, will trip things
up. Irony here is that it's those same assembler routines that trip up
traditional unwinders. Anyway, an unwinder capable of unwinding just LR
works pretty well.
GCC CFI leaves registers as "unspecified" and the "assume same value"
hack isn't sufficient. For PPC64, GCC points the "return_column" at
dwarf2 num 65 (that's the FPSCR but lets ignore that m'key :-). It
needs to specify that by default the "return_column" has the same value
as the "LR" column.
So while trad unwind code is useful, I think it can now be considered
largely optional.
I've got more GCC bugs to file :-)
enjoy,
Andrew
WARNING: multiple messages have this Message-ID
From: Andrew Cagney <ac131313@redhat.com>
To: gdb@sources.redhat.com
Subject: GDB without traditional frames
Date: Thu, 25 Sep 2003 14:45:00 -0000 [thread overview]
Message-ID: <3F724CAE.3040502@redhat.com> (raw)
Message-ID: <20030925144500.2lC5Ea3mQQdiSYC21JGF9JMkPTAMNmOl0mKArl5iRcs@z> (raw)
Hello,
As an accademic exercise I decided to see what would happen if a PPC64
GDB was configured to only use dwarf2 cfi (just disable the trad-frame
code).
The short answer is "it works (mostly)".
The long answer is ...
It relies on there being 100% coverage of the CFI. System libraries can
sometimes be lacking. Assembler stubs, for instance, will trip things
up. Irony here is that it's those same assembler routines that trip up
traditional unwinders. Anyway, an unwinder capable of unwinding just LR
works pretty well.
GCC CFI leaves registers as "unspecified" and the "assume same value"
hack isn't sufficient. For PPC64, GCC points the "return_column" at
dwarf2 num 65 (that's the FPSCR but lets ignore that m'key :-). It
needs to specify that by default the "return_column" has the same value
as the "LR" column.
So while trad unwind code is useful, I think it can now be considered
largely optional.
I've got more GCC bugs to file :-)
enjoy,
Andrew
next reply other threads:[~2003-09-25 2:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-25 2:02 Andrew Cagney [this message]
2003-09-25 14:45 ` Andrew Cagney
2003-09-26 21:36 ` y2bismil
2003-09-26 21:54 ` Daniel Berlin
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=3F724CAE.3040502@redhat.com \
--to=ac131313@redhat.com \
--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