From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27585 invoked by alias); 18 Mar 2003 05:13:52 -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 27520 invoked from network); 18 Mar 2003 05:13:51 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 18 Mar 2003 05:13:51 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18vBJX-0004FJ-00; Tue, 18 Mar 2003 01:15:11 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18v9Q4-000595-00; Tue, 18 Mar 2003 00:13:48 -0500 Date: Tue, 18 Mar 2003 05:13:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() Message-ID: <20030318051348.GA19741@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <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> <3E7670F6.9060906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E7670F6.9060906@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00270.txt.bz2 On Mon, Mar 17, 2003 at 08:05:58PM -0500, Andrew Cagney wrote: > >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. So in this case should we be hooking the get_frame_base() call to return the computed DW_AT_frame_base? If so, we're going to need to go through all the uses and computations of the frame base in all targets for consistency. And what happens if we don't have DWARF-2 information? I guess I just don't see how this evolves. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer