linkonce and dwarf 2

[Jason Merrill <jason at cygnus dot com>]

So, I've been thinking about schemes for eliminating duplicate dwarf2 debug
information without having to deal with the linker reading it all in and
writing it out again.

For those less familiar with dwarf2, debug info is divided into
"compilation units" (CUs), which don't necessarily correspond to object
files, though commonly they do.  Usually, references between DIEs (Debug
Info Entries) are via an offset from the beginning of the CU, but they can
also be via an offset from the beginning of the .debug_info section, for
exactly this purpose.

1) One scheme that ought to work fine is to put the DIE
for a class into its own CU, which would go into a linkonce section and be
pasted onto .debug_info by the linker script.  The problem with this is
that you would pay the CU overhead for each such class; it works out to at
least 16 bytes for a minimal CU header, though when we're dealing with
classes like streambuf that have 6k of debug info, maybe that's not so bad.

2) Another scheme would be to have only one additional CU.  Each class
would still get its own section, and the link would cause the CU header to
be wrapped around the classes which weren't discarded from that object; I'm
assuming that if you have sections in two objects like

   .debug_info_head
   .gnu.linkonce.d.1A
   .gnu.linkonce.d.f__Fv
   .debug_info_tail

and the link script says

   .debug_info : { *(.debug_info* .gnu.linkonce.d.*) }

then the section contents will retain the above order in the output, rather
than lumping all the _head bits together and so on.

The problem with this scheme is that the CU header specifies the length of
the CU, and there would be no way to compute this at compile or assembly
time; it would depend on which subsections had been kept or thrown away.
Is there currently any way to express link-time arithmetic in gas?

3) Another scheme would be to do something like the stabs BINCL
optimization, and put all the info for a header into its own CU.  This
would also be useful for C, while the two schemes above would mainly work
for C++ (because of the stronger rules for type names in C++).  The problem
with this scheme is that it would require linkonce and symbol resolution
semantics like those of the BINCL optimization; we would only want to
discard duplicates if they were identical, and we would want references to
be bound to the appropriate instance if not all are discarded.

Hmm...it occurs to me that rather than just keying off the header name, we
could do a checksum of the debug info we're generating and include that in
the section name and symbol names.  That ought to do the trick without any
linker changes.

Any thoughts?

Jason