From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sourceware.org
Subject: [RFC] Move the frame zero PC check earlier
Date: Wed, 10 May 2006 18:03:00 -0000 [thread overview]
Message-ID: <20060510180312.GA12606@nevyn.them.org> (raw)
In this patch:
http://sourceware.org/ml/gdb-patches/2004-12/msg00328.html
Andrew added a generic check for two "normal" frames in a row where the
older one has a saved PC of zero. This is pretty well understood as a
convention for terminating backtraces - either intentionally or
unintentionally.
The problem is, given where that check takes place, it is in my opinion one
frame off from the actual problem. You get backtraces that look like this:
(gdb) bt
#0 catcher (sig=11) at /space/fsf/commit/src/gdb/testsuite/gdb.base/savedregs.c:43
#1 0x00002ac148ec6e90 in killpg () from /lib/libc.so.6
#2 0x0000000000000000 in ?? ()
On the one hand, that third frame is a nice marker for this case in that it
explains noisily that GDB is confused. In this case, if I point GDB at
.debug_frame data for my C library (conveniently found by default in
/usr/lib/debug) it successfully backtraces through to main, so that's good.
On the other hand, that third frame is ugly and generally useless. The
attached patch moves the check one frame earlier, so that we only get this
backtrace:
#0 catcher (sig=11) at /space/fsf/commit/src/gdb/testsuite/gdb.base/savedregs.c:43
#1 0x00002ac148ec6e90 in killpg () from /lib/libc.so.6
Benefits: cleaner looking backtraces; the check is only done once per frame
instead of on every call to get_prev_frame. Disadvantages: for all frames
at level > 0, it causes this check to be done when we look at THIS frame
instead of when we unwind to the PREV frame, which forces us to locate the
correct sniffer earlier. If you have a sigtramp sniffer which reads memory,
this might cause an extra memory read. However, it won't happen in the
critical stepping path - we don't need this check when "unwinding frame 0
from the sentinel frame - so I think this is an acceptable tradeoff. For
any frame other than the top frame, the thing you're most likely to do with
it is backtrace right through it.
Tested on x86_64-pc-linux-gnu, and by hand against SymbianOS, where it gives
much nicer looking backtraces.
Any comments?
--
Daniel Jacobowitz
CodeSourcery
2006-05-10 Daniel Jacobowitz <dan@codesourcery.com>
* frame.c (get_prev_frame): Move check for pc == 0 ...
(get_prev_frame_1): ... to here.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.211
diff -u -p -r1.211 frame.c
--- frame.c 17 Dec 2005 22:33:59 -0000 1.211
+++ frame.c 10 May 2006 17:48:32 -0000
@@ -1123,6 +1123,26 @@ get_prev_frame_1 (struct frame_info *thi
this_frame->prev = prev_frame;
prev_frame->next = this_frame;
+ /* Now that the frame chain is in a consistant state, check whether
+ this frame is useful. If it is not, unlink it. Its storage will
+ be reclaimed the next time the frame cache is flushed, and we
+ will not try to unwind THIS_FRAME again. */
+
+ /* Assume that the only way to get a zero PC is through something
+ like a SIGSEGV or a dummy frame, and hence that NORMAL frames
+ will never unwind a zero PC. This will look up the unwinder
+ for the newly created frame, to determine its type. */
+ if (prev_frame->level > 0
+ && get_frame_type (prev_frame) == NORMAL_FRAME
+ && get_frame_type (this_frame) == NORMAL_FRAME
+ && get_frame_pc (prev_frame) == 0)
+ {
+ if (frame_debug)
+ fprintf_unfiltered (gdb_stdlog, "-> // zero PC}\n");
+ this_frame->prev = NULL;
+ return NULL;
+ }
+
if (frame_debug)
{
fprintf_unfiltered (gdb_stdlog, "-> ");
@@ -1300,18 +1320,6 @@ get_prev_frame (struct frame_info *this_
return NULL;
}
- /* Assume that the only way to get a zero PC is through something
- like a SIGSEGV or a dummy frame, and hence that NORMAL frames
- will never unwind a zero PC. */
- if (this_frame->level > 0
- && get_frame_type (this_frame) == NORMAL_FRAME
- && get_frame_type (get_next_frame (this_frame)) == NORMAL_FRAME
- && get_frame_pc (this_frame) == 0)
- {
- frame_debug_got_null_frame (gdb_stdlog, this_frame, "zero PC");
- return NULL;
- }
-
return get_prev_frame_1 (this_frame);
}
next reply other threads:[~2006-05-10 18:03 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 18:03 Daniel Jacobowitz [this message]
2006-05-11 10:42 ` Andrew STUBBS
2006-05-11 22:24 ` Jim Blandy
2006-05-11 22:32 ` Daniel Jacobowitz
2006-05-12 6:21 ` Jim Blandy
2006-05-12 12:46 ` Daniel Jacobowitz
2006-05-13 10:14 ` Mark Kettenis
2006-05-13 15:17 ` Daniel Jacobowitz
2006-05-13 15:46 ` Daniel Jacobowitz
2006-05-13 17:08 ` Mark Kettenis
2006-05-13 16:49 ` Mark Kettenis
2006-05-13 18:53 ` Daniel Jacobowitz
2006-05-16 21:38 ` Daniel Jacobowitz
2006-05-16 22:19 ` Mark Kettenis
2006-05-16 22:46 ` Daniel Jacobowitz
2006-05-16 23:53 ` PAUL GILLIAM
2006-05-18 1:35 ` Joel Brobecker
2006-05-18 9:31 ` Jim Blandy
2006-05-18 10:09 ` Andrew STUBBS
2006-05-18 17:36 ` Jim Blandy
2006-05-18 18:09 ` PAUL GILLIAM
2006-05-18 20:04 ` Jim Blandy
2006-05-18 20:43 ` Mark Kettenis
2006-05-18 23:31 ` Jim Blandy
2006-05-20 22:26 ` Mark Kettenis
2006-05-21 2:12 ` Daniel Jacobowitz
2006-07-21 15:52 ` Andrew STUBBS
2006-07-22 11:23 ` Mark Kettenis
2006-07-24 19:32 ` Daniel Jacobowitz
2006-07-26 22:16 ` Mark Kettenis
2006-07-26 22:25 ` Daniel Jacobowitz
2006-05-19 3:32 ` Daniel Jacobowitz
2006-05-20 21:30 ` Mark Kettenis
2006-05-19 12:26 ` Eli Zaretskii
2006-05-19 18:12 ` Jim Blandy
2006-05-19 18:53 ` Eli Zaretskii
2006-05-22 23:15 ` Jim Blandy
2006-05-15 13:57 ` Andrew STUBBS
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=20060510180312.GA12606@nevyn.them.org \
--to=drow@false.org \
--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