This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[rfa] classes, partial symtabs, and DW_AT_specification
- From: David Carlton <carlton at kealia dot com>
- To: gdb-patches at sources dot redhat dot com
- Cc: Elena Zannoni <ezannoni at redhat dot com>, Daniel Jacobowitz <drow at mvista dot com>
- Date: Fri, 23 Jan 2004 16:40:48 -0800
- Subject: [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;