From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9530 invoked by alias); 26 Mar 2003 21:00:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9514 invoked from network); 26 Mar 2003 21:00:58 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 26 Mar 2003 21:00:58 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18yJuX-0001Dr-00; Wed, 26 Mar 2003 17:02:21 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18yI0z-0005sK-00; Wed, 26 Mar 2003 16:00:53 -0500 Date: Wed, 26 Mar 2003 21:00:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch rfc] Per-frame frame-base Message-ID: <20030326210053.GA22425@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3E820F82.6050803@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E820F82.6050803@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00525.txt.bz2 On Wed, Mar 26, 2003 at 03:37:22PM -0500, Andrew Cagney wrote: > The implementation is very much modeled on the frame-unwind code. Debug > readers are expected to register their own high level frame-base handler. So what will the process for getting a dwarf2-debug-info frame registered look like? How will we figure out that this function has dwarf2 debug info? It's not trivial... we don't have that information around any more on a per-PC basis. I'll have to think. > +/* Assuming that a frame is `normal', return the address of the first > + local variable, or 0 if the information isn't available. NOTE: > + This address is really only meaningful to the frame's high-level > + debug info. Typically, the argument and locals share a single > + base-address. */ > +extern CORE_ADDR get_frame_locals_address (struct frame_info *); > + > +/* Assuming that a frame is `normal', return the address of the first > + parameter, or 0 if that information isn't available. NOTE: This > + address is really only meaningful to the frame's high-level debug > + info. Typically, the argument and locals share a single > + base-address. */ > +extern CORE_ADDR get_frame_args_address (struct frame_info *); > + Address of the first parameter / address of the first argument isn't correct I think. It's the base address for parameters and the base address from locals. They're likely to be the same but with different offsets. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer