From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28212 invoked by alias); 2 Sep 2009 17:33:40 -0000 Received: (qmail 28202 invoked by uid 22791); 2 Sep 2009 17:33:39 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Sep 2009 17:33:33 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5625610DCE for ; Wed, 2 Sep 2009 17:33:30 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 3628810D18 for ; Wed, 2 Sep 2009 17:33:30 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Miti4-0007QY-Q5 for gdb-patches@sourceware.org; Wed, 02 Sep 2009 13:33:28 -0400 Date: Wed, 02 Sep 2009 17:33:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: RFC: Mark outer frames Message-ID: <20090902173328.GA28209@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20090828213237.GA9175@caradoc.them.org> <20090902170324.GC4365@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090902170324.GC4365@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes 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-09/txt/msg00067.txt.bz2 On Wed, Sep 02, 2009 at 10:03:24AM -0700, Joel Brobecker wrote: > > The obvious pitfall is that the outer frame isn't a single consistent > > frame. So there's an ugly bit in infrun that says if we set the stack > > pointer while inside an outer frame, and suddenly we're in a frame we > > think we can unwind from (mostly incorrectly at this point), then > > we've not changed functions. Otherwise stepping through _start will > > blow up on some platforms I tried. > > Didn't we have the same problem with null_frame_id before? I guess > not because equality to the null_frame_id is always false... The bit > in infrun does not seem all that horrible to me, but your comment does > suggest another way that you might think is better? Sorry, I meant to go into that. The magic outer frame ID is, IMO, a workaround. What we really want is to have frame IDs wherever we can. Either "stack address uncertain, but function known" or even "stack address and function known, but outerness detected". This requires changes to the unwinding interface, and additional changes to each affected unwinder to build the best IDs we can and to mark the outer frame some other way. I haven't spec'd out a full approach to this problem, just speculated about it. > + /* The outermost frame marker is equal to itself. This is the > + dodgy think about outer_frame_id, since between execution steps > ^^^^^ thing > Thanks! > I wouldn't mind a more detailed comment about when outer_frame_id > should be used (we're in startup code and the associated frame has > not been setup yet). I got confused by "there is no frame ID, but > there is a frame". This is, indeed, the central problem. -- Daniel Jacobowitz CodeSourcery