From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27891 invoked by alias); 12 Jun 2003 17:01:38 -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 27832 invoked from network); 12 Jun 2003 17:01:37 -0000 Received: from unknown (HELO coconut.kealia.com) (216.101.126.244) by sources.redhat.com with SMTP; 12 Jun 2003 17:01:37 -0000 Received: from dhcp-10-42-69-238.kealia.com (coconut.kealia.com [127.0.0.1]) by coconut.kealia.com (8.12.8/8.12.8) with ESMTP id h5CH1dQ4017087; Thu, 12 Jun 2003 10:01:39 -0700 Received: (from carlton@localhost) by dhcp-10-42-69-238.kealia.com (8.12.8/8.12.8/Submit) id h5CH1cah017085; Thu, 12 Jun 2003 10:01:38 -0700 X-Authentication-Warning: dhcp-10-42-69-238.kealia.com: carlton set sender to carlton@kealia.com using -f To: gdb Cc: Daniel Jacobowitz , Elena Zannoni , Jim Blandy Subject: DW_AT_specification and partial symtabs From: David Carlton Date: Thu, 12 Jun 2003 17:01:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00208.txt.bz2 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.) For example, a couple of weeks ago I fixed a bug on the branch where I wasn't setting the names of types mentioned via DW_AT_type properly. (I introduced parent pointers in the symtab reader's tree of DIEs so we could get at that information.) Today I want to deal with the fact that DW_AT_specification can lead you to hop around the tree of DIEs. This was already going to be a little messy, but then I realized that this issue affects not only symtabs but also psymtabs. Specifically, say we have code like this: namespace N { class C; } class N::C { public: int foo; }; Then a compiler might choose to create a DW_TAG_namespace die for N whose child is a DW_TAG_class_type die for C that's just a declaration; then, outside of the DIE for N, it might have a DW_TAG_class_type die for N::C that gives the actual definition but has a DW_AT_specification that points at the declaration for C within N. Schematically: 1) comp unit DIE 2) die for N 3) declaration for N::C 4) definition of N::C (with specification pointing to 3) Then the only way that we'll know that C lives within N (and hence should be called N::C instead of just C) is by following that DW_AT_specification (to die 3) and realizing that it is a child of die 2. 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 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)? David Carlton carlton@kealia.com