From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-27106-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 12750 invoked by alias); 12 Dec 2006 13:55:15 -0000
Received: (qmail 12413 invoked by uid 22791); 12 Dec 2006 13:55:12 -0000
X-Spam-Check-By: sourceware.org
Received: from cpc1-cmbg8-0-0-cust558.cmbg.cable.ntl.com (HELO zebedee.littlepinkcloud.COM) (82.6.106.47)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Dec 2006 13:55:05 +0000
Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) 	by zebedee.littlepinkcloud.COM (8.13.6/8.13.5) with ESMTP id kBCDsm32028159; 	Tue, 12 Dec 2006 13:54:48 GMT
Received: (from aph@localhost) 	by littlepinkcloud.COM (8.13.6/8.13.5/Submit) id kBCDslLr028156; 	Tue, 12 Dec 2006 13:54:47 GMT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17790.46246.634400.638852@zebedee.pink>
Date: Tue, 12 Dec 2006 13:55:00 -0000
From: Andrew Haley <aph@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gcc@gcc.gnu.org, libc-alpha@sources.redhat.com, gdb@sourceware.org,         Jakub Jelinek <jakub@redhat.com>, Richard Henderson <rth@redhat.com>
Subject: Re: Unwinding CFI gcc practice of assumed `same value' regs
In-Reply-To: <20061211190300.GA4372@host0.dyn.jankratochvil.net>
References: <20061211190300.GA4372@host0.dyn.jankratochvil.net>
X-Mailer: VM 7.19 under Emacs 21.4.1
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-12/txt/msg00092.txt.bz2

Jan Kratochvil writes:

 > currently (on x86_64) the gdb backtrace does not properly stop at
 > the outermost frame:
 > 
 > #3  0x00000036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
 > #4  0x00000036dd0c68c3 in clone () from /lib64/tls/libc.so.6
 > #5  0x0000000000000000 in ?? ()
 > 
 > Currently it relies only on clearing %rbp (0x0000000000000000 above is
 > unrelated to it, it got read from uninitialized memory).

That's how it's defined to work: %rbp is zero.  

 > http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame
 > pointer 0x0 should be enough for a debugger not finding CFI to stop
 > unwinding, still it is a heuristic.

Not by my understanding it isn't.  It's set up by the runtime system,
and 0 (i.e. NULL on x86-64) marks the end of the stack.  Officially.

See page 28, AMD64 ABI Draft 0.98 \u2013 September 27, 2006 -- 9:24.

Andrew.