From: Andrew Cagney <cagney@gnu.org>
To: gdb-patches@sources.redhat.com
Subject: [patch/rfc] The off again, on again, PC == 0 in get_prev_frame
Date: Fri, 20 Feb 2004 21:27:00 -0000 [thread overview]
Message-ID: <40367BCD.8090403@gnu.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]
Ref: [PATCH] Don't try to unwind the PC in frame.c:get_prev_frame()
http://sources.redhat.com/ml/gdb-patches/2004-01/msg00104.html
Having only recently posted:
> Can just you add a -ve comment stating why a test for PC==0 does not belong in that function? I'm pretty much certain that someone will eventually try to re-add a very similar test (via inside_entry_func for instance).
the attached adds a conditionalized check for "PC == 0" to
get_prev_frame. If there's a zero PC, _and_ it isn't the inner most
frame, stop unwinding. That should let mark's original case through.
Turns out that the old removed test was stopping this problem on amd64:
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's
print
where
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at
/home/cygnus/cagney/GD
B/src/gdb/testsuite/gdb.threads/linux-dp.c:105
#1 0x0000000000400e4a in philosopher (data=0x50177c) at
/home/cygnus/cagney/GDB
/src/gdb/testsuite/gdb.threads/linux-dp.c:148
#2 0x0000002a95671c2b in start_thread () from /lib64/tls/libpthread.so.0
#3 0x0000002a959de040 in thread_start () from /lib64/tls/libc.so.6
#4 0x0000000000000000 in ?? ()
#5 0x0000000000000000 in ?? ()
#6 0x0000000000000000 in ?? ()
#7 0x0000000000000000 in ?? ()
#8 0x0000000000000000 in ?? ()
#9 0x0000000000000000 in ?? ()
#10 0x0000000000000000 in ?? ()
#11 0x0000000000000000 in ?? ()
#12 0x0000000000000000 in ?? ()
#13 0x0000000000000000 in ?? ()
#14 0x0000000000000000 in ?? ()
#15 0x0000000000000000 in ?? ()
#16 0x0000002a95b41580 in _nl_C_locobj () from /lib64/tls/libc.so.6
#17 0x00000000427ffdc8 in ?? ()
comments (...)
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1955 bytes --]
2004-02-20 Andrew Cagney <cagney@redhat.com>
* frame.c (get_prev_frame): With the exception of the inner-most
frame, do not backtrace past a frame with a zero pc.
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.162
diff -u -r1.162 frame.c
--- frame.c 16 Feb 2004 21:49:21 -0000 1.162
+++ frame.c 20 Feb 2004 21:12:52 -0000
@@ -1721,14 +1721,9 @@
return prev;
}
-/* Return a structure containing various interesting information
- about the frame that called THIS_FRAME. Returns NULL
- if there is no such frame.
-
- This function tests some target-independent conditions that should
- terminate the frame chain, such as unwinding past main(). It
- should not contain any target-dependent tests, such as checking
- whether the program-counter is zero. */
+/* Return a structure containing various interesting information about
+ the frame that called THIS_FRAME. Returns NULL if there is no such
+ frame. */
struct frame_info *
get_prev_frame (struct frame_info *this_frame)
@@ -1843,6 +1838,24 @@
fprint_frame (gdb_stdlog, NULL);
fprintf_unfiltered (gdb_stdlog, "// inside entry func }\n");
}
+ return NULL;
+ }
+
+ /* Don't allow frames with a zero PC to unwind. The exception is
+ the inner-most frame - a jump through a NULL pointer results in
+ an inner most frame that is both unwindable and has a zero
+ PC. */
+ /* NOTE: cagney/2004-02-20: The old zero PC check, removed
+ 2004-01-11, had the problem that it stopped backtraces from that
+ inner most zero PCed frame. */
+ if (this_frame->level > 0 && get_frame_pc (this_frame) == 0)
+ {
+ if (frame_debug)
+ {
+ fprintf_unfiltered (gdb_stdlog, "-> ");
+ fprint_frame (gdb_stdlog, NULL);
+ fprintf_unfiltered (gdb_stdlog, " // PC zero }\n");
+ }
return NULL;
}
next reply other threads:[~2004-02-20 21:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-20 21:27 Andrew Cagney [this message]
2004-02-20 23:23 ` Mark Kettenis
2004-02-22 17:40 ` Andrew Cagney
2004-02-22 21:10 ` Mark Kettenis
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=40367BCD.8090403@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@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