From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13444 invoked by alias); 7 Jul 2009 12:00:23 -0000 Received: (qmail 13429 invoked by uid 22791); 7 Jul 2009 12:00:22 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jul 2009 12:00:12 +0000 Received: from relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 067598D893; Tue, 7 Jul 2009 14:00:09 +0200 (CEST) Date: Tue, 07 Jul 2009 12:00:00 -0000 From: Michael Matz To: Mark Kettenis Cc: drow@false.org, gdb-patches@sourceware.org Subject: Re: RFC: %ebp-based backtrace patch In-Reply-To: <200907062157.n66LvSVF007634@brahms.sibelius.xs4all.nl> Message-ID: References: <20090706183316.GA26074@caradoc.them.org> <200907062157.n66LvSVF007634@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00187.txt.bz2 Hi, On Mon, 6 Jul 2009, Mark Kettenis wrote: > Makes sense to me. If we have no clue where we are anymore, taking > the gamble that %ebp is a valid frame pointer probably has better odds > than that %esp points to a valid frame. This will need a comment > though. I'll take care of that. > > There is one potential problem though. IIRC early versions of the > vsyscall DSO did not have embedded debug information. That was indeed quite some time ago, probably not useful to care anymore. But I took a quick look at the current implementations. Some of them use %ebp frames, so those would be fine even without debug info (and broken with the current heuristic), and some use no frame at all (hence the heuristic of %esp-4 would work). The latter will use the frame of the caller with the new heuristic, which is not ideal but somewhat okay when that caller itself has a %ebp frame. If it hasn't, everything is off. All of that is problematic only for non-debug-info vsyscalls/vDSOs, which I'd hope don't exist in practice anymore. One thing of note: we meanwhile use the Fedora package of gdb, mostly unchanged. One patch of it interacts with the new heuristic, namely gdb-6.5-bz218379-ppc-solib-trampoline-fix.patch . That patch isn't necessary anymore and in any case never really did what it intended. The result of it is that the frame unwinder magically always finds a "function" (the fake minimal symbols for trampolines, not to be confused with "function@plt" symbols) for each program counter, even of length zero. That breaks the heuristic again. Ciao, Michael.