[rfa] classes, partial symtabs, and DW_AT_specification

[rfa] classes, partial symtabs, and DW_AT_specification

[David Carlton]

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;
 

Re: [rfa] classes, partial symtabs, and DW_AT_specification

[Daniel Jacobowitz]

What a coincidence you should raise this subject... :)

On Fri, Jan 23, 2004 at 04:40:48PM -0800, David Carlton wrote:
> 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.

I have no objection to this as a workaround, although it makes me feel
a bit filthy :)

> 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?

We don't need anything from GCC.  We have everything we need already;
we just need to do things (very) differently.  Coincidentally, we
already have another reason to do things differently.  I am working on
inter-CU reference support again; if we can't find parents then there's
no point in building psymtabs, since we won't be able to cope with the
first reference to another CU that isn't nested directly under the CU
DIE.

With a little tuning, I think this is a solvable problem.  It will
probably take a speed hit, but smaller debug info will hopefully make
up for a lot of that.  And then, if someone implements
.debug_info_index, we can use that for psymtabs instead.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa] classes, partial symtabs, and DW_AT_specification

[Elena Zannoni]

David Carlton writes:
 > 
 > 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.

Is there an associated bug number that should be mentioned in the changelog?

 > 
 > 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?
 > 

Sure. Commit away.

elena

Re: [rfa] classes, partial symtabs, and DW_AT_specification

[David Carlton]

On Wed, 28 Jan 2004 12:09:03 -0500, Elena Zannoni <ezannoni@redhat.com> said:
> David Carlton writes:

>> 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.

> Is there an associated bug number that should be mentioned in the
> changelog?

Nope.

> Commit away.

Thanks, committed.  (After replacing cu_language by cu->language.)

David Carlton
carlton@kealia.com

Re: [rfa] classes, partial symtabs, and DW_AT_specification

[David Carlton]

On Sun, 25 Jan 2004 12:00:31 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Fri, Jan 23, 2004 at 04:40:48PM -0800, David Carlton wrote:

>> 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.

> I have no objection to this as a workaround, although it makes me feel
> a bit filthy :)

I know the feeling...

>> 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?

> We don't need anything from GCC.  We have everything we need already;
> we just need to do things (very) differently.

Yeah.  For the issue I ran into, it's probably not _too_ hard to
solve: we could build up a die->parent table that only covered the
dies that we would want to parse while reading the psymtabs - the spec
die that I'm looking for should already be such a die.  But using this
as an excuse to step back and think about how we want dwarf2 psymtabs
to work in an ideal world would certainly be a good idea.

> I am working on inter-CU reference support again; if we can't find
> parents then there's no point in building psymtabs, since we won't
> be able to cope with the first reference to another CU that isn't
> nested directly under the CU DIE.

Ah.

> With a little tuning, I think this is a solvable problem.  It will
> probably take a speed hit, but smaller debug info will hopefully
> make up for a lot of that.  And then, if someone implements
> .debug_info_index, we can use that for psymtabs instead.

Do you have a reference for .debug_info_index?  I tried searching for
it, but nothing turned up; I couldn't find an archive for the dwarf2
mailing list.

David Carlton
carlton@kealia.com

Re: [rfa] classes, partial symtabs, and DW_AT_specification

[Daniel Jacobowitz]

On Wed, Jan 28, 2004 at 10:51:20AM -0800, David Carlton wrote:
> Yeah.  For the issue I ran into, it's probably not _too_ hard to
> solve: we could build up a die->parent table that only covered the
> dies that we would want to parse while reading the psymtabs - the spec
> die that I'm looking for should already be such a die.  But using this
> as an excuse to step back and think about how we want dwarf2 psymtabs
> to work in an ideal world would certainly be a good idea.

Hmm, that is an interesting idea.  It may be worthwhile.

> > With a little tuning, I think this is a solvable problem.  It will
> > probably take a speed hit, but smaller debug info will hopefully
> > make up for a lot of that.  And then, if someone implements
> > .debug_info_index, we can use that for psymtabs instead.
> 
> Do you have a reference for .debug_info_index?  I tried searching for
> it, but nothing turned up; I couldn't find an archive for the dwarf2
> mailing list.

There's no archive.  Someone, IIRC Jim, proposed it before I joined the
dwarf2 list; the basic concept is that it's exactly the same format as
.debug_info, but with less information.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer