From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16107 invoked by alias); 2 Sep 2009 17:03:41 -0000 Received: (qmail 16032 invoked by uid 22791); 2 Sep 2009 17:03:39 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Sep 2009 17:03:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C01592BABA7 for ; Wed, 2 Sep 2009 13:03:32 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eIHovJol0UDL for ; Wed, 2 Sep 2009 13:03:32 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 866832BABE9 for ; Wed, 2 Sep 2009 13:03:32 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 955CEF589A; Wed, 2 Sep 2009 10:03:24 -0700 (PDT) Date: Wed, 02 Sep 2009 17:03:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: RFC: Mark outer frames Message-ID: <20090902170324.GC4365@adacore.com> References: <20090828213237.GA9175@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090828213237.GA9175@caradoc.them.org> User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00063.txt.bz2 FWIW: > 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? > Thoughts? Does this actually help with 9711? Is it too ugly to live? This does not strike me as something that would set us back in terms of maintenance. I like the idea of splitting null_frame_id in two different entities with a narrower meaning. The heuristic in infrun is a little unfortunate, but not the worse I've seen by a large measure. I would personally be OK with that patch, especially if it's useful to others (Doug, for instance). + /* The outermost frame marker is equal to itself. This is the + dodgy think about outer_frame_id, since between execution steps ^^^^^ thing 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". -- Joel