From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6296 invoked by alias); 20 Feb 2004 23:23:45 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6288 invoked from network); 20 Feb 2004 23:23:44 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 20 Feb 2004 23:23:44 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1KNNbt6000885; Sat, 21 Feb 2004 00:23:37 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1KNNbL8027103; Sat, 21 Feb 2004 00:23:37 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i1KNNaL4027099; Sat, 21 Feb 2004 00:23:36 +0100 (CET) Date: Fri, 20 Feb 2004 23:23:00 -0000 Message-Id: <200402202323.i1KNNaL4027099@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com In-reply-to: <40367BCD.8090403@gnu.org> (message from Andrew Cagney on Fri, 20 Feb 2004 16:27:41 -0500) Subject: Re: [patch/rfc] The off again, on again, PC == 0 in get_prev_frame References: <40367BCD.8090403@gnu.org> X-SW-Source: 2004-02/txt/msg00569.txt.bz2 Date: Fri, 20 Feb 2004 16:27:41 -0500 From: Andrew Cagney 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