This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/rfc] The off again, on again, PC == 0 in get_prev_frame
- From: Mark Kettenis <kettenis at chello dot nl>
- To: cagney at gnu dot org
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 21 Feb 2004 00:23:36 +0100 (CET)
- Subject: Re: [patch/rfc] The off again, on again, PC == 0 in get_prev_frame
- References: <40367BCD.8090403@gnu.org>
Date: Fri, 20 Feb 2004 16:27:41 -0500
From: Andrew Cagney <cagney@gnu.org>
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
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 ?? ()
Andrew, I think that this case is completely broken. The frame chain
isn't properly terminated. The clone(2) system call that has created
this thread tries to mark frame #3 as the outermost frame by clearing
%rbp. However, since most amd64 code doesn't use the frame pointer,
this is pointless; GDB doesn't look at it. The fact that you're
seeing a zero PC here is merely accidental; it just happens to be that
(%rsp) contains zero. Therefore I don't think we should consider a
zero PC as a marker for the end of the frame chain.
The Linux folks should add proper CFI to the implementation of
close(2) in glibc. A DW_CFA_def_cfa rule that sets the CFA to %rbp
should do the trick.
Mark