From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31728 invoked by alias); 12 Dec 2006 15:04:44 -0000 Received: (qmail 31700 invoked by uid 22791); 12 Dec 2006 15:04:43 -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 15:04:39 +0000 Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5) with ESMTP id kBCF4JiA025266; Tue, 12 Dec 2006 15:04:19 GMT Received: (from aph@localhost) by littlepinkcloud.COM (8.13.6/8.13.5/Submit) id kBCF4HR5024780; Tue, 12 Dec 2006 15:04:17 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17790.50417.668957.495292@zebedee.pink> Date: Tue, 12 Dec 2006 15:04:00 -0000 From: Andrew Haley To: "Mark Kettenis" Cc: "Jan Kratochvil" , gcc@gcc.gnu.org, libc-alpha@sources.redhat.com, gdb@sourceware.org, "Jakub Jelinek" , "Richard Henderson" Subject: Re: Unwinding CFI gcc practice of assumed `same value' regs In-Reply-To: <22844.82.92.89.47.1165935102.squirrel@webmail.xs4all.nl> References: <20061211190300.GA4372@host0.dyn.jankratochvil.net> <17790.46246.634400.638852@zebedee.pink> <22844.82.92.89.47.1165935102.squirrel@webmail.xs4all.nl> X-Mailer: VM 7.19 under Emacs 21.4.1 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00095.txt.bz2 Mark Kettenis writes: > > 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. > > Unfortunately whoever wrote that down didn't think it through. In > Figure 3.4 on page 20, %rbp is listed as "callee-saved register; > optionally used as frame pointer". So %rbp can be used for anything, as > long as you save its contents and restore it before you return. Null-terminating the call stack is too well-established practice to be changed now. In practice, %ebp either points to a call frame -- not necessarily the most recent one -- or is null. I don't think that having an optional frame pointer mees you can use %ebp for anything random at all, but we need to make a clarification request of the ABI. > Since it may be used for anything, it may contain 0 at any point in > the middle of the call stack. > So it is unusable as a stack trace termination condition. The only > viable option is explicitly marking it as such in the CFI. > > Initializing %rbp to 0 in the outermost frame is sort of pointless > on amd64. The right way to fix the ABI is to specify that %ebp mustn't be [mis]used in this way, not to add a bunch more unwinder data. Andrew.