From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30376 invoked by alias); 17 Mar 2003 17:11:46 -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 30276 invoked from network); 17 Mar 2003 17:11:45 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 17 Mar 2003 17:11:45 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18v02j-00039c-00; Mon, 17 Mar 2003 13:13:05 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18uy9G-0004Hf-00; Mon, 17 Mar 2003 12:11:42 -0500 Date: Mon, 17 Mar 2003 17:11:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() Message-ID: <20030317171142.GA15367@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E75FE48.9000104@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00258.txt.bz2 On Mon, Mar 17, 2003 at 11:56:40AM -0500, Andrew Cagney wrote: > >On Mon, Mar 17, 2003 at 11:22:35AM -0500, Andrew Cagney wrote: > > > >> > > > >>>>However, shouldn't the only thing needing the `virtual frame pointer' / > >>>>get_frame_base() be the code that needs a virtual base pointer when > >>>>computing the value of a local variable? > > > >>> > >>> > >>>Yes, and that's the only time that we search for the frame base. But > >>>what difference does it make? > > > >> > >>(gdb) info frame > >> > >>will display the correct value. > > > > > >What does "correct" mean though? > > Display the frame's `virtual base pointer'. > > >>>At that point we have an offset that we > >>>know is relative to DW_AT_frame_base, but we don't know if it's > >>>relative to what the rest of GDB considers the frame base (since we > >>>never use DW_AT_frame_base to compute the frame base in the first > >>>place; and it's not clear to me that we should be). > > > >> > >>Where, apart from `info frame', and variable evaluation, is it correct > >>for GDB to use the frame base? > > > > > >I'm sorry, but I just don't understand what you're asking. We use the > >frame base all over. > > > >The current frame base (i.e. id.base) is produced by target specific > >code - often via prologue analysis; on x86-64 via CFI; etc. > > Er, > > >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? The current get_frame_base does return ->frame but you also say above that get_frame_base should return get_frame_id().base. Conceptually, are frame->frame and frame->id.base supposed to be the same? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer