From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7328 invoked by alias); 12 Jun 2003 17:05:50 -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 7319 invoked from network); 12 Jun 2003 17:05:49 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 12 Jun 2003 17:05:49 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19QVX0-0008EJ-00; Thu, 12 Jun 2003 12:06:34 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19QVWE-0004RG-00; Thu, 12 Jun 2003 13:05:46 -0400 Date: Thu, 12 Jun 2003 17:05:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb , Elena Zannoni , Jim Blandy Subject: Re: DW_AT_specification and partial symtabs Message-ID: <20030612170545.GA16995@nevyn.them.org> Mail-Followup-To: David Carlton , gdb , Elena Zannoni , Jim Blandy References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00209.txt.bz2 On Thu, Jun 12, 2003 at 10:01:38AM -0700, David Carlton wrote: > One of the main issues that I'm dealing with on my branch is getting > nested types to work right in C++ (with DWARF 2): these have the > characteristic that they depend on the hierarchical structure of the > debug info to a greater extent than, as far as I can tell, anything > that mainline GDB currently does. The reason for this is that, to > deduce a nested type's name, you really have to know where it lives in > the hierarchical structure, so you can add whatever prefixes are > appropriate to its DW_AT_name. (With non-types, we (over)use mangled > names for this sort of thing, so it's not such a big deal there.) > Unfortunately, there's no way to get at that information at all with > the current psymtab reader: it tries to march from top-level DIE to > top-level DIE without building up a tree of DIEs. So it seems to me > that I have no choice but to have the psymtab reader build up a tree > of DIEs before it starts reading, just like the symtab reader does. > > Comments? Suggestions? Ideas for how to make the tree that the > psymtab reader builds to be as small as possible? I'm a little > worried about weird cases like local classes: if I have I'll answer this in more depth in a bit. For now, something to consider: I would like to add .debug_typenames (spelling?) to GCC - it's an SGI extension, IIRC. This plus .debug_pubnames should allow us to implement psymtabs entirely without mapping .debug_info. I believe it handles your case too, since it should have fully qualified typenames. The implementation may need a little tweaking for space efficiency... > void foo () > { > class Local { > public: > int mem() {return 1;} > }; > > ... > } > > then is the compiler allowed to put a definition of Local::mem as a > child of the comp unit die (with a DW_AT_specification pointing to a > DIE inside of foo somewhere)? I believe so. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer