From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [PATCH] Lift DWARF unwinder restriction in dwarf2-frame.c::dwarf2_frame_cfa
Date: Fri, 21 Nov 2014 03:59:00 -0000 [thread overview]
Message-ID: <1416542375-742-1-git-send-email-brobecker@adacore.com> (raw)
Hello,
GDB is currently broken on all SPARC targets when using GCC 4.9.
When trying to print any local variable:
(gdb) p x
can't compute CFA for this frame
This is related to the fact that the compiler now generates DWARF 4
debugging info by default, and in particular that it now emits
DW_OP_call_frame_cfa, which triggers a limitation in dwarf2_frame_cfa:
/* This restriction could be lifted if other unwinders are known to
compute the frame base in a way compatible with the DWARF
unwinder. */
if (!frame_unwinder_is (this_frame, &dwarf2_frame_unwind)
&& !frame_unwinder_is (this_frame, &dwarf2_tailcall_frame_unwind))
error (_("can't compute CFA for this frame"));
We couldn't append the dwarf2 unwinder to all SPARC targets because
it does not work properly with StackGhost:
https://www.sourceware.org/ml/gdb-patches/2014-07/msg00012.html
We also later discovered that using the DWARF2 unwinder means
using it for computing the function's return address, which
is buggy when it comes to functions returning a struct (where
the return address is saved-pc+12 instead of saved-pc+8).
This is because GCC is emitting the info about the return address
as %o7/%i7 instead of the actual return address. For functions
that have debugging info, we compensate by looking at the function's
return type and add the extra +4, but for function without debug
info, we're stuck.
EricB and I twisted the issue in all the directions we could think of,
and unfortunately couldn't find a way to make it work without
introduction one regression or another.
But, stepping back a little, just removing the restriction seems to work
well for us on all both sparc-elf and {sparc,sparc64}-solaris.
After reviewing the previous discussions about this test, I could
not figure out whether some unwinders were already known to have
incompatible CFAs or if the concern was purely theoretical:
https://www.sourceware.org/ml/gdb-patches/2009-06/msg00191.html
https://www.sourceware.org/ml/gdb-patches/2009-07/msg00570.html
https://www.sourceware.org/ml/gdb-patches/2009-09/msg00027.html
At the moment, we took the approach of trying it out, and see what
happens...
gdb/ChangeLog:
PR backtrace/16215:
* dwarf2-frame.c (dwarf2_frame_cfa): Remove the restriction
the frame unwinder must either be the dwarf2_frame_unwind
or the dwarf2_tailcall_frame_unwind. Verify that this_frame's
stack_addr is valid before calling get_frame_base. Throw
an error if not valid.
Tested on sparc-solaris and sparc-elf with AdaCore's testsuite
(the FSF testsuite crashes all of AdaCore's solaris machines).
OK to commit?
Thank you,
--
Joel
---
gdb/dwarf2-frame.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/gdb/dwarf2-frame.c b/gdb/dwarf2-frame.c
index 80e5903..30a24c8 100644
--- a/gdb/dwarf2-frame.c
+++ b/gdb/dwarf2-frame.c
@@ -1512,12 +1512,12 @@ dwarf2_frame_cfa (struct frame_info *this_frame)
throw_error (NOT_AVAILABLE_ERROR,
_("can't compute CFA for this frame: "
"required registers or memory are unavailable"));
- /* This restriction could be lifted if other unwinders are known to
- compute the frame base in a way compatible with the DWARF
- unwinder. */
- if (!frame_unwinder_is (this_frame, &dwarf2_frame_unwind)
- && !frame_unwinder_is (this_frame, &dwarf2_tailcall_frame_unwind))
- error (_("can't compute CFA for this frame"));
+
+ if (get_frame_id (this_frame).stack_status != FID_STACK_VALID)
+ throw_error (NOT_AVAILABLE_ERROR,
+ _("can't compute CFA for this frame: "
+ "frame base not available"));
+
return get_frame_base (this_frame);
}
\f
--
1.7.10.4
next reply other threads:[~2014-11-21 3:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 3:59 Joel Brobecker [this message]
2014-12-13 13:27 ` pushed: " Joel Brobecker
2014-12-31 7:23 ` pushed/gdb-7.8-branch: " Joel Brobecker
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=1416542375-742-1-git-send-email-brobecker@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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).