From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30285 invoked by alias); 24 Jan 2004 00:41:25 -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 30278 invoked from network); 24 Jan 2004 00:41:24 -0000 Received: from unknown (HELO coconut.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 24 Jan 2004 00:41:24 -0000 Received: from coconut.kealia.com (localhost.localdomain [127.0.0.1]) by coconut.kealia.com (8.12.8/8.12.8) with ESMTP id i0O0enSH007214; Fri, 23 Jan 2004 16:40:49 -0800 Received: (from carlton@localhost) by coconut.kealia.com (8.12.8/8.12.8/Submit) id i0O0emLQ007212; Fri, 23 Jan 2004 16:40:48 -0800 X-Authentication-Warning: coconut.kealia.com: carlton set sender to carlton@kealia.com using -f To: gdb-patches@sources.redhat.com Cc: Elena Zannoni , Daniel Jacobowitz Subject: [rfa] classes, partial symtabs, and DW_AT_specification From: David Carlton Date: Sat, 24 Jan 2004 00:41:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg00642.txt.bz2 This is another DW_AT_specification problem that crops up with GCC 3.4. The picture is this: namespace N { class C { // definition of N::C }; } gives rise to this in GCC 3.4: 1: DW_TAG_compile_unit 2: DW_TAG_namespace // N 3: DW_TAG_structure_scope // declaration for N::C 4: DW_TAG_structure_scope // definition for N::C DW_AT_specification => points to die #3. When building the partial symbol table for this file, we look for definitions of classes; but, when we see the definition for N::C, the only way we know from the debug info that we're within namespace N is by following DW_AT_specification. Which we can't do with our psymtabs. This is a serious design problem with our psymtab structure, which we've known about for a while. Either we need to add into it a fast way to follow DW_AT_specification links _and_ then figure out the parent of the die at the other end, or we need help from the compiler, or something. In any event, any correct solution would be a major undertaking; the best way to deal with the situation for now is to use demangled names when we run into this situation, just like we would if the compiler weren't generating DW_TAG_namespace at all. Tested on i686-pc-linux-gnu, DWARF-2, 4 different GCC variants; no regressions, and on GCC 3.4 two tests in rtti.exp went from {K}FAIL to PASS. OK to commit? I guess I need symtab approval, though Daniel should feel free to chime in as well. :-) And at some point we really need to develop a plan of attack for DWARF-2 partial symbols - what improvements can we do without GCC's help, what help do we want from GCC? David Carlton carlton@kealia.com 2004-01-23 David Carlton * dwarf2read.c (add_partial_structure): Use demangled name if namespace equals "". Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.124 diff -u -p -r1.124 dwarf2read.c --- dwarf2read.c 23 Jan 2004 22:41:28 -0000 1.124 +++ dwarf2read.c 24 Jan 2004 00:05:37 -0000 @@ -1660,12 +1660,12 @@ add_partial_structure (struct partial_di char *actual_class_name = NULL; if (cu_language == language_cplus - && namespace == NULL + && (namespace == NULL || namespace[0] == '\0') && struct_pdi->name != NULL && struct_pdi->has_children) { - /* We don't have namespace debugging information, so see if we - can figure out if this structure lives in a namespace. Look + /* See if we can figure out if the class lives in a namespace + (or is nested within another class.) We do this by looking for a member function; its demangled name will contain namespace info, if there is any. */ @@ -1674,6 +1674,21 @@ add_partial_structure (struct partial_di frequently doesn't give the same name as the debug info. We could fix this by only using the demangled name to get the prefix (but see comment in read_structure_scope). */ + + /* FIXME: carlton/2004-01-23: If NAMESPACE equals "", we have + the appropriate debug information, so it would be nice to be + able to avoid this hack. But NAMESPACE may not be the + namespace where this class was defined: NAMESPACE reflects + where STRUCT_PDI occurs in the tree of dies, but because of + DW_AT_specification, that may not actually tell us where the + class is defined. (See the comment in read_func_scope for an + example of how this could occur.) + + Unfortunately, our current partial symtab data structures are + completely unable to deal with DW_AT_specification. So, for + now, the best thing to do is to get nesting information from + places other than the tree structure of dies if there's any + chance that a DW_AT_specification is involved. :-( */ char *next_child = info_ptr;