From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23731 invoked by alias); 18 Mar 2003 04:29:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23501 invoked from network); 18 Mar 2003 04:29:01 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 18 Mar 2003 04:29:01 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B11E52B11; Mon, 17 Mar 2003 20:05:58 -0500 (EST) Message-ID: <3E7670F6.9060906@redhat.com> Date: Tue, 18 Mar 2003 04:29:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() References: <3E74F4F4.50003@redhat.com> <20030316221008.GA19037@nevyn.them.org> <3E75121F.4030405@redhat.com> <20030317001407.GA20827@nevyn.them.org> <3E75F64B.5040700@redhat.com> <20030317163843.GA11494@nevyn.them.org> <3E75FE48.9000104@redhat.com> <20030317171142.GA15367@nevyn.them.org> <3E7611EC.3020304@redhat.com> <20030317193537.GA11288@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00269.txt.bz2 > On Mon, Mar 17, 2003 at 01:20:28PM -0500, Andrew Cagney wrote: > >> > >> >>>GDB's frame code also makes available the get_frame_base() method. While >> >>>the default implementation returns get_frame_id().base, I think there is >> >>>going to need to be a per-frame frame->unwind->this_base method. > >> > > >> >> >> >>get_frame_base() returns ->frame and NOT ->id.base. > >> > >> > >> >OK, I'm definitely going around in confused little circles. Don't the >> >two statements above disagree? > >> >> No. See get_prev_frame() where it is defaulting ->frame to ->id.base. >> > >> > The current get_frame_base does return >> >->frame but you also say above that get_frame_base should return >> >get_frame_id().base. > >> >> No. Default to get_frame_id().base. > > > So is that supposed to be a statement about the future in the first > paragraph? It's sure not worded as one, no wonder I'm confused. The present. GDB historically has had FRAME_FP and frame->frame and their intended purposes were overloaded: per frame unique identifier, frame base pointer, ... Frame ID provides a per-frame unique identifier. >> >Conceptually, are frame->frame and frame->id.base supposed to be the >> >same? > >> >> No? > > > Then could you enlighten me as to what the difference is supposed to > be? For dwarf2, check the spec where it discuss CFA (see CFI) and frame-base (see 3.3.5). CFA + &function == frame_id A per frame unique identifier that must be constant through out the lifetime of the frame. CFI recommends the top-of-stack from the previous frame. frame-base == get_frame_base() What ever the debug info would like it to be. The ISAs ABI will provide a strong set of guidelines though (if, for a framed function it doesn't match what the user expects, the'll likely complain :-). It will often point into the middle of the stack frame. Andrew