DW_AT_specification and partial symtabs

[David Carlton <carlton at kealia dot com>]

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