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

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

From:	brender 19-JAN-2001 17:38:57.34
To:	SMTP%"jason@redhat.com"
CC:	BRENDER
Subj:	Re: duplicate dwarf2 reduction via comdat

Jason writes:
>Early in the process, I talked about the scheme I implemented in GCC
>without extending the 2.0 spec.  The code for this scheme is present in the
>current CVS sources for the compiler, but is disabled by default, pending
>final cleanup work and GDB support for FORM_ref_addr.
>
>I had also proposed at least one extension (AT_extension on
>TAG_compilation_unit) to allow my scheme to be more efficient.  As I
>recall, that change was rejected, and there was a request for me to write
>up my scheme in more detail, but I never did.  So here we go:

My recollection is not so much that we rejected it as that we did not
feel we understood the proposal as a whole enough to be clear on how
DW_AT_extension fit in -- at least that was my perspective.

>(Note: I haven't read Dave's email yet.  I will soon.)

----

>The basic idea of my scheme is to separate chunks of potentially duplicated
>information out into their own COMDAT sections, to be recombined into the
>monolithic .debug_info section by the linker.  No attempt is currently made
>to optimize the other DWARF sections, and we currently only do this for
>header files.
>
>Each header file, then, is given its own compilation unit, in addition to
>the primary compilation unit corresponding to the primary source file.
>References between these compilation units use FORM_ref_addr, of course.
>
>The CU for the header file contains only the "interface" parts of the
>header, namely types.  The "implementation" parts, i.e. anything with a
>location attribute, remain in the primary CU, since they correspond to
>actual code in the object file.
>
>For consistency and collision protection, the COMDAT key for a particular
>compilation unit is generated from the basename of the header file and a
>checksum of the contents.  The (global) symbols used for references to DIEs
>in these CUs are composed of this key and a sequence number.  References

I'm with ya up to this point, but the next loses me...

>from the header CUs to the primary CU use internal symbols; there is no
>need for them to be consistent between two CUs for the same header, so long
>as they refer to (semantically) the same thing.

What do you mean by "internal symbols"?

The "no need for consistency" assertion just doesn't seem obvious.
Is there some way to explain this in more detail?

>There are some issues with the current draft that make this less effective
>than it could be.  For one, 3.3.8.3 says that a concrete out-of-line
>instance of an inline function needs to be owned by the same parent as the
>abstract instance, which prevents us from putting them in different CUs.
>Does anyone know what the rationale for this rule is?  It seems entirely
>arbitrary to me.

I can't think of a rationale either at the moment...

>It would also be nice to be able to provide debugging info for an abstract
>version of a template, to reduce the redundancy between instantiations.
>
>Also, it should be possible to do the AT_declaration/AT_specification thing
>with nested types; if a nested type is only defined in the implementation
>.cc file for a class, the compiler should be able to put its definition at
>file scope.  This also would remove the necessity for going back and
>modifying previously generated information; nested types are the downfall
>of the gcc dwarf1 generator, which tries hard to write everything out
>immediately and forget about it.

By "nested types" do you mean things like classes within classes?
It sounds like there is a sort of "if the source (or DWARF) looks like
this, transform it to this other form" proposal here. An example sure
would help.

>This scheme could be further extended by putting the information for
>COMDATted code into a separate CU in the same COMDAT group with the
>function itself.

I'm not up to speed enough to make yet another generalization...

>Thoughts?  Questions?

Completely help me understand sorts of questions (see above) at the moment.
I think some kind of more concrete example would help a lot.

Ron
================== RFC 822 Headers ==================
Date: Fri, 19 Jan 2001 17:23:36 -0500
Message-Id: <01011917233678@gemevn.zko.dec.com>
From: brender@gemevn.zko.dec.com (Ron 603-884-2088)
To: jason@redhat.com, BRENDER@gemevn.zko.dec.com
Subject: Re: duplicate dwarf2 reduction via comdat
X-VMS-To: SMTP%"jason@redhat.com"
X-VMS-Cc: BRENDER