Re: duplicate dwarf2 reduction via comdat

[brender at gemgrp dot zko dot dec dot com (Ron 603-884-2088)]

E-mail from Jason and the resulting interchanges seem to demonstrate
that a useful degree of DWARF duplicate elimination can be accomplished with
just the mechanisms that are already available in DWARF V2.

However, it seems to me that there are still a couple rather fundamental
strategy questions whose resolution could help us focus on reaching a
resolution of this problem.

Recall that back on 22 Jan I suggested that a complete solution needed
four components:

> 1) A "subunit" DIE which provides a means to represent a sequence of
>    DIEs corresponding (broadly) to a list of declarations. It has no
>    scoping implications, being merely DWARF glue unrelated to particular
>    source language semantics. It has a name by which it may be identified
>    from other compilation units.
>...
>
> 2) A "separate" or "include" DIE which represents the place in
>    a compilation unit where logically belong the declarations of the
>    subunit it identifies (using the subunit's name).
>
>...
> 3) A new form used to reference a DIE in a subunit, let me call it
>    DW_FORM_ref_separate, whose representation is a pair of values:
>      - An unsigned LEB number which is a reference to the separate
>        subunit DIE (per 2) in the current unit that identifies the
>        separate subunit of interest
>      - A string (offset in .debug_Str) which names (by some convention TBD)
>        the item in the separate subunit that is the "target" of the reference.
>
>...
>
> 4) Some set of naming conventions for identifying subunits and for
>    identifying the DIEs within them.

Against that background, it seems to me that Jason has pretty successfully
demonstrated that it is possible to do without a new FORM of operand,
relying solely on linker global symbols. This makes it unnecessary to
make a proposal along the lines of my bullet 3).

  Question #1:  Is everyone comfortable with using linktime global symbols
		for references into "comdatted" information, and satisfied
		that a new form of operand is not needed? (References from
		inside comdatted information to a containing non-comdatted
		unit are also possible without using global symbols.)

I think I am pretty much convinced. Is there anyone who thinks this still
requires discussion?

A limitation of Jason's scheme, I think, is that it results in comdatted
information that is "promoted" to the level of a compilation unit and
which becomes logically visible across all module scopes when in fact
it should be visible only in some units. This limitation becomes rather
more serious, I think, if you try to use this sort of technique to handle
duplicate template instantiations and/or unreferenced function elimination.
At least, I do not yet see that there is a generalization that deals with
these additional "opportunities".

  Question #2:  Is everyone comfortable with these limitations? Or should
		we formulate and consider a proposal for some kind of
		SUBUNIT and INCLUDE DIEs to try to eliminate the the
		limitations and extend the technique?

I think I would like to see some kind of SUBUNIT and INCLUDE DIEs proposed.

Finally, Jason has not described his exact hash function or the criteria
in detail for can and cannot be included in comdatted information. This
is consistent with my suggestion that bullet 4) should be left as
implementation defined.

  Question #3:  Is everyone comfortable with *not* including a precise and
		complete description in the DWARF standard of a viable
		hash function and candidate inclusion rules?

I agree with this position, although it does make it a
bit unclear how to explain the actual scheme and its use in the document.
It is desirable to have some kind of worked example, at least say in the
Appendices.

If members of this list could try to address these three questions in
particular, I think it would provide some useful guidance and direction
about what next steps to take toward closure.

Thanks,
Ron