Re: [patch/rfc] The off again, on again, PC == 0 in get_prev_frame

[Mark Kettenis <kettenis@chello.nl>]

   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