From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14305 invoked by alias); 21 Nov 2002 02:26:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14295 invoked from network); 21 Nov 2002 02:26:13 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 21 Nov 2002 02:26:13 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DA6E03E4B; Wed, 20 Nov 2002 21:25:57 -0500 (EST) Message-ID: <3DDC4435.1080504@redhat.com> Date: Wed, 20 Nov 2002 18:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] FRAME_FP() -> get_frame_base() References: <3DDA9741.4050001@redhat.com> <1021120213809.ZM26349@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00511.txt.bz2 > I think get_frame_base() is a good choice. I like get_frame_address() > too, but if using "base" somehow helps us to remember that this > address remains constant, then that's a good thing. I should note that I really don't have a preference. Depending on the time of day, I'll favour get_frame_address() or get_frame_base(). > [...] > >> - (I guess) re-vamp the PPC so that get_frame_base() is constant through >> out the lifetime of a frame. > > > Yes, I guess so. I had to think about this a while though -- the current > placement of ->frame makes a lot of sense. Yes, given the PPC ABIs, the current code does make a lot of sense. I've looked at changing it before but backed away. The PPC could easily maintain both pointers. Have get_frame_XXX() return a constant, but locally, use the stack top. Two technical points, I think, swing things in favour of the change: - gdb really needs a constant frame address if it is going to correctly re-locate a frame after a target resume. Without this, gdb can't get edge cases right. Eg, consider a stack like: outer() middle() inner() #1 which is then transformed to: outer() middle() inner() #1 inner() #2 Unless the frame is constant, gdb would mistake inner()#2 for inner()#1. - the dummy frame code, for the PPC, needs to do a stack upwind when trying to identify a dummy frame. It should be possible to avoid this. Andrew