From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13231 invoked by alias); 12 Jun 2003 17:20:26 -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 13140 invoked from network); 12 Jun 2003 17:20:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 12 Jun 2003 17:20:24 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5CHKOH13873 for ; Thu, 12 Jun 2003 13:20:24 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5CHKOI01566 for ; Thu, 12 Jun 2003 13:20:24 -0400 Received: from localhost.redhat.com (IDENT:Ir2Fx3IcR5b/ycn/oem8dGOBXYPs/Af5@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5CHKMe00397; Thu, 12 Jun 2003 13:20:22 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 590632C986; Thu, 12 Jun 2003 13:26:51 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16104.47067.182016.78574@localhost.redhat.com> Date: Thu, 12 Jun 2003 17:20:00 -0000 To: Daniel Jacobowitz Cc: David Carlton , gdb , Elena Zannoni , Jim Blandy Subject: Re: DW_AT_specification and partial symtabs In-Reply-To: <20030612170545.GA16995@nevyn.them.org> References: <20030612170545.GA16995@nevyn.them.org> X-SW-Source: 2003-06/txt/msg00211.txt.bz2 Daniel Jacobowitz writes: > 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 wonder, if we are not reaching the end of the usefulness of the psymtabs. I mean, if we start making the psymtab reader behave like the symtab reader, how much faster is that going to be, how much smaller, etc. I need to go reread the old threads on this. elena > 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