This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[rfa] classes, partial symtabs, and DW_AT_specification


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  <carlton@kealia.com>

	* 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;
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]