Thoughts on enablers for DWARF duplicate elimination

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

Prior to the 9 January DWARF meeting I suggested that there might be some
enablers toward DWARF duplicate elimination, short of a full solution, that
would be worth incorporating into the current almost finished revision.
Dave A, Ulrich D and I got "appointed" to see whether something useful
could be accomplished. Accordingly I wrote up and sent the following comments
along to Dave and Ulrich the following day. Neither Dave nor Ulrich ever
responded and now Dave is on vacation (and will be for another week).

Jason has since suggested what sounds like a simpler approach (perhaps dealing
with only part of the problem) although I admit to still not following some
key aspects of his proposal.

I am forwarding my earlier comments to Dave and Ulrigh along to the full
DWARF list in the hopes that it may in some way help contribute to the
discussion and possible convergence on a viable approach.

--------------------------------------------------------------------------------
From:	brender 10-JAN-2001 09:29:05.48
To:	ANDERSON, DREPPER
CC:	BRENDER
Subj:	Thoughts on enablers for DWARF duplicate elimination

Dave, Ulrich:

At the 9 January DWARF meeting, the three of us got anointed as a subcommittee,
with Dave as lead, to explore whether there is something more that can be
done to facilitate duplicate elimination in DWARF symbol tables. Since I
helped launch us into this role by suggesting that there might be some
"enablers" short of a complete solution that could be worthwhile, here let
me attempt a quick sketch of what I have in mind.

Despite Dave's bashful intent to rewrite his email of 26 October for clarity
and organization, it is a very valuable analysis that contains a lot of
insight. It leads me to believe that there are four components needed for
a full solution:

 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.

    TBD is whether a subunit should be a second kind of compilation unit,
    sharing the use of many of the same attributes as the DW_TAG_compile_unit
    DIE or whether it should always be contained in a compilation unit
    having only attributes specific to its subunitness.

    Dave called this a section group. Same concept, different name for the
    purposes of this sketch.

    NOTE: we suspect in our hearts that subunits correspond to COMDATs,
    but we will resist saying that. All we ask is that at debug time,
    there must be an environment (OS) provided function that will map
    from the name of the subunit to the offset (in memory? in the image
    file?) where the beginning of the subunit is located.

 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.

    NOTE: 2) and 3) together serve much the same function as Dave's
    suggested DW_FORM_ref_group. I suggest splitting into two parts
    for two reasons:
      - some lists of declarations should have a logical place in the
        lexical/nesting structure of the program representation, as
	well as being referenceable from "outside"
      - An LEB offset to something in the current unit will almost always
        be smaller/more compact than a necessarily target address sized
	offset into the .debug_str section (and not require a relocation
	either).
    But I digress...

 4) Some set of naming conventions for identifying subunits and for
    identifying the DIEs within them.

    It is TBD whether it would be beneficial to allow an additional
    DW_AT_separate_name attribute to establish the non-program name
    for this purpose or whether some kind of super-mangling is appropriate.

So far I hope what I am sketching looks remarkably like what Dave described.

So what is my proposal? Simply that we define items 1), 2) and 3) as additions
to the DWARF standard and leave 4) as the province of an implementation.

I suggest as a rationale that this is akin to not specifying any particular
C++ mangling scheme even though we "know" some names will be mangled and
even indicate the need for a mangled rather than simple name in certain places
in the DWARF document.

	This approach will (hopefully) permit each implementation to
	build its own scheme but not assure interoperability between
	implementations, even on the same platform. That is true today
	for C++ for many reasons (object model, mangling) that we (DWARF)
	will never overcome in any case. There is some hope, however, that
	the first implementation of C and Fortran 90 on a platform might
	"define the standard" naming conventions for that platform in a
	way suitable for other implementations to follow (simply because
	the duplicate problem is somewhat simpler for C, much simpler for
	Fortran [modules]).

Now the hard part: I am confident that we can construct a set of proposals
along the lines sketched,  and pretty much convince ourselves that they
provide key building blocks for duplicate suppression; but, can we
convince the rest of the committee that we are "right on" rather than
"almost right but not quite good enough"?

Perhaps we could do enough of a design for 4) to be convinced of the
viability of 1)-4) without including 4) in the document?

Hopefully I have communicated what I have in mind without getting bogged
down in too much detail--everything is negotiable at this point (except
the requirement to convince the full committee :-).

Any and all thoughts are welcome!!!

Ron


================== RFC 822 Headers ==================
Date: Wed, 10 Jan 2001 09:28:18 -0500
Message-Id: <01011009281813@gemgrp.zko.dec.com>
From: brender@gemgrp.zko.dec.com (Ron 603-884-2088)
To: DAVEA@engr.sgi.com, DREPPER@cygnus.com, BRENDER@gemgrp.zko.dec.com
Subject: Thoughts on enablers for DWARF duplicate elimination
X-VMS-To: ANDERSON, DREPPER
X-VMS-Cc: BRENDER