From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7152 invoked by alias); 13 Dec 2006 18:10:05 -0000 Received: (qmail 7127 invoked by uid 22791); 13 Dec 2006 18:10:03 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Dec 2006 18:09:53 +0000 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id EA62021597; Wed, 13 Dec 2006 19:09:46 +0100 (CET) Date: Wed, 13 Dec 2006 18:10:00 -0000 From: Michael Matz To: Jan Kratochvil Cc: 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: <20061211190300.GA4372@host0.dyn.jankratochvil.net> Message-ID: References: <20061211190300.GA4372@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/msg00117.txt.bz2 Hi, On Mon, 11 Dec 2006, Jan Kratochvil wrote: > 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). > > 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. In the -fno-frame-pointer compiled > code there is no indication the frame pointer register became a regular > one and 0x0 is its valid value. Right. Unwinding through functions (without frame pointer) requires CFI. If there is CFI for a function the unwinder must not look at %rbp for stop condition. If there's no CFI for a function it can't be unwound (strictly per ABI). If one relaxes that and wants to unwind through CFI-less functions it has to have a frame pointer. In that case zero in that frame pointer could indicate the outermost frame (_if_ the suggestion in the ABI is adhered to, which noone is required to). Ciao, Michael.