Re: C++ and multiple compilation units

[Jim Blandy <jimb@zwingli.cygnus.com>]

Daniel Berlin <dan@cgsoftware.com> writes:
> In fact, dwarf2.1 adds an imported_unit/partial_unit tag so that you
> can comdat just about everything, and not screw up the scope
> (partial_unit means ignore it when scanning toplevel cu's, we read
> it in when we see the imported_unit tag))

This is new in Draft 6, right?

> >  Does GCC generate these inter-CU
> > references now? 
> 
> No, but only because GDB can't handle them
> Let me rephrase that. It *can* generate them, it just defaults to not doing so.
> -feliminate-dwarf2-dups is the flag to turn it on.

Okay.

> >   Do you have a test case?
> I can easily generate them, if you like. It's pretty trivial.

That would be really helpful.

> The inter-die cu references is what started the need the rewrite.
> We assume everywhere we are only processing the current CU, and
> never have to move between them.

That's right.

> So i rewrote the whole damn thing to pass around a structure that
> contains the compilation unit context to do whatever in.  When we need
> to switch between compilation units, we just change the context we are
> passing around, reading in the abbrevs/whatever for that cu if
> necessary.

But once we've called read_comp_unit, we're not going any more I/O ---
we've turned the whole CU into a linked list (which should be a tree)
of `struct die_info' nodes.  So if we find a reference to another
compilation unit, it seems to me we could just call read_comp_unit
again, and extend our die list (and reference table).

We'd need a map of where each compilation unit starts and ends, so we
could tell which CU to read when we find a reference that falls
outside of our own.  But that's easily produced when we build the
partial symbols.

Suppose further that we restructured `struct die_info' to be a real
tree, not a linked list whose tree structure is only apparent from the
presence of null dies.  Each die could have a parent pointer, which
would allow us to produce scoped names.

This *sounds* a bit simpler than your changes.  But I haven't actually
done the work, so I can't be sure.