From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5246 invoked by alias); 7 Jul 2009 12:15:33 -0000 Received: (qmail 5236 invoked by uid 22791); 7 Jul 2009 12:15:33 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jul 2009 12:15:23 +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 321DA867E2; Tue, 7 Jul 2009 14:15:20 +0200 (CEST) Date: Tue, 07 Jul 2009 12:15:00 -0000 From: Michael Matz To: "Frank Ch. Eigler" Cc: gdb-patches@sourceware.org, Mark Kettenis Subject: Re: RFC: %ebp-based backtrace patch In-Reply-To: Message-ID: References: <20090706183316.GA26074@caradoc.them.org> 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/msg00188.txt.bz2 Hi, On Mon, 6 Jul 2009, Frank Ch. Eigler wrote: > Daniel Jacobowitz writes: > > > A number of Linux distributions are carrying the attached patch from > > Michael Matz. [...] > > https://bugzilla.novell.com/show_bug.cgi?id=390722#c25 > >[...] > > * i386-tdep.c (i386_frame_cache): Assume anonymous functions use > > a frame pointer. > >[...] > > Could gdb partially disassemble such functions to check > whether %ebp is likely being used as this heuristic expects? Nope. We don't know the function borders. But there's another heuristic that could potentially be useful: check if %ebp points not too far away from %esp (and has a higher value). That way we would at least reject functions that use %ebp to hold some low integer values. Then we of course have the problem again of having to rely on %esp-4 containing the return address. That assumption doesn't really hold very often. In fact it holds _only_ for frameless functions, of which there aren't that many on x86. So we're screwed either way. Ciao, Michael.