Re: duplicate dwarf2 reduction via comdat [overlooked CC to dwarf2 list]

[Jason Merrill <jason at redhat dot com>]

>>>>> "Ron" == Ron 603-884-2088 <brender@gemevn.zko.dec.com> writes:

> Finally the key point: after the linker has eliminated one of I#1 or
> I#2, the remaining I will still refer an entity within the same unit with
> which it was co-compiled. Whether you think of that reference in terms of
> symbols or offsets within sections does not matter--all that matters is
> that whatever I#1 referred to (which can occur anywhere in A) is semantically
> equivalent to whatever I#2 referred to (which can occur anywhere in B).

Exactly.

>  3) implement the reference from J into I using some kind of global
>     (in the object file sense) necessarily mangled name (because of
>     the use of a global symbol)

> But, the third approach is what must be used to refer into I (whether I#1
> or I#2) from either A or B in any case. So, no new problems arise.

Right.

> Finally, I think I do see a real semantic limitation of your scheme.
> That is that there is nothing in the representation that conveys the
> fact that the declarations of, say, included file I.h should be "visible"
> from the module scope of A.c and C.c but *not* from some other unit C.c
> that does not include I.h. (Indeed, scope information cannot be built
> into the global mangled name used to reference into I because the same
> name must be used for references from both A and B.)

In C++, class names must be unique across all units, so this is not an
issue.  It would be a problem for C, though.

> Perhaps limitation is acceptable in light of the space benefits obtained?
> I am still pondering that one. (You may recall that the enabling mechanisms
> I suggested included a new DW_TAG_include or DW_TAG_separate DIE, whose
> purpose was to avoid this limitation.)

Seems reasonable.  This sort of thing would also work with my scheme
(with the new TAG referring symbolically to the header CU DIE).

> Am I getting this all correct?

Looks like it.  It seems to me that my separation strategy would work
equally well with my current implementation using symbolic references, or
Dave's/your suggested implementation using internal names; they're just
different ways of representing the same thing.  My scheme has the advantage
of needing fewer changes to the spec, though it does produce a lot of
symbols for the linker to deal with.

Jason