From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26475 invoked by alias); 18 Mar 2003 16:38:10 -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 26426 invoked from network); 18 Mar 2003 16:38:09 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 18 Mar 2003 16:38:09 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18vLzl-0005Du-00; Tue, 18 Mar 2003 12:39:29 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18vJM2-0006rh-00; Tue, 18 Mar 2003 10:50:18 -0500 Date: Tue, 18 Mar 2003 16:38:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() Message-ID: <20030318155007.GA26362@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <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> <20030318051348.GA19741@nevyn.them.org> <3E773325.8090001@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E773325.8090001@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00276.txt.bz2 On Tue, Mar 18, 2003 at 09:54:29AM -0500, Andrew Cagney wrote: > > > >So in this case should we be hooking the get_frame_base() call to > >return the computed DW_AT_frame_base? [...] And what happens if we don't > >have DWARF-2 > >information? > > At the start I wrote: > > > For dwarf2 frames, it would return, DW_AT_frame_base. For prologue > frames, it would return an attempt at an equivalent value. Hopefully it > wouldn't be called for other frame types :-). OK. I'll make the assumption that the DW_AT_frame_base and the CFA in the dwarf2 unwind information (if both present) will agree. If they don't, well... we'll have to deal with that later. > A better question is, what about other debug types? The definition of > the frame-base is dependant on the debug info. > > Dig dig. Other debug info (e.g., LOC_LOCAL) depends on > FRAME_LOCALS_ADDRESS(). So to take this a step further, it is a merged > FRAME_LOCALS_ADDRESS() + get_frame_base() that is needs to become per frame. > > > If so, we're going to need to go > > through all the uses and computations of the frame base in all targets > > for consistency. > > All existing calls to get_frame_base() in core-gdb need to be audited > anyway :-( This is so that breakage such as VALUE_FRAME() can finally > be laid to rest (see "frame.h", "frame ID" for why get_frame_base() > isn't up to the task). Yep. Thanks for holding my hand through this; I think I'm back on the same page now. I agree that eventually the business with evaluating the DW_AT_frame_base should be reduced to a get_frame_base call, although it may be... a little while. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer