From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2147 invoked by alias); 16 Mar 2003 22:10: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 2088 invoked from network); 16 Mar 2003 22:10:10 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Mar 2003 22:10:10 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18uiDx-0001Ym-00; Sun, 16 Mar 2003 18:11:29 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18ugKW-0004xa-00; Sun, 16 Mar 2003 17:10:08 -0500 Date: Sun, 16 Mar 2003 22:10:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() Message-ID: <20030316221008.GA19037@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <3E74F4F4.50003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E74F4F4.50003@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00239.txt.bz2 On Sun, Mar 16, 2003 at 05:04:36PM -0500, Andrew Cagney wrote: > At present there is a per-frame ID method since different frames > determine their ID using different techniques. The ID (which identifies > a given frame instance) includes a base and pc/func value. > > 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. > > 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 :-). > > It might even be reasonable for a prologue based unwinder to error out > when asked for the frame's base before the stack frame has been created. > > Thoughts? > > I should note that dwarf2expr.c contains code that tries to > locally/directly evaluate the frame base. I think that should instead > do a get_frame_base() call. There's no guarantee right now that the DW_AT_frame_base agrees with the frame's base. I don't even think it's necessary that they be the same. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer