From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30943 invoked by alias); 26 Mar 2003 22:22:55 -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 30932 invoked from network); 26 Mar 2003 22:22:54 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 26 Mar 2003 22:22:54 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18yLBr-0001Nc-00; Wed, 26 Mar 2003 18:24:20 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18yJIJ-0006Pu-00; Wed, 26 Mar 2003 17:22:51 -0500 Date: Wed, 26 Mar 2003 22:22:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch rfc] Per-frame frame-base Message-ID: <20030326222251.GA24651@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3E820F82.6050803@redhat.com> <20030326210053.GA22425@nevyn.them.org> <3E8220D1.90007@redhat.com> <20030326215841.GA24011@nevyn.them.org> <3E822738.4070403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E822738.4070403@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00530.txt.bz2 On Wed, Mar 26, 2003 at 05:18:32PM -0500, Andrew Cagney wrote: > >On Wed, Mar 26, 2003 at 04:51:13PM -0500, Andrew Cagney wrote: > > > >>>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? > > > >> > >>The current interface is identical to frame-unwind. > >> > > > >>>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. > > > >> > >>Ask the frame's function's symbol or block. > > > > > >Symbols don't currently have this information, nor do blocks. > > Well, at least the partial symtab does, sort of implicit via > read_symtab. Shame that location_funcs stuff wasn't a symbol wide > virtual function table. I heard a volunteer running away into the woods, where did he go? It took over a year to get location_funcs in at all. Obviously using any of these frame cleanups is going to require cleanups in the symtab. I don't know who will be interested in doing them however. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer