Re: DWARF compaction

["Cary Coutant" <ccoutant at google dot com>]

> This subject is well-understood among DWARF experts and the solutions long
> planned.  Indeed the great bulk of the work here is on the producer side.
> There are ways that involve new compiler and linker smarts cooperating
> (this scheme is described in an appendix to the DWARF spec), as well as
> ways done in a pure post-processing step without the compiler or linker
> doing anything different (though post-processing integrated into linking is
> also an offshoot of this option).

I've actually been working on this problem recently, and I submitted a
draft proposal last month to the DWARF workgroup to add features that
allow each type to be placed in its own comdat section, using an MD5
hash of the type info as a type signature. Apple apparently tried
something similar a couple of years ago, but it looks like they've
given up on it. I'm very nearly done with a gcc patch to try this out
and see how much space I can really save.

The solution described in the DWARF appendix is, I believe, already
implemented in gcc as -fdwarf2-eliminate-dups, but it doesn't appear
to have ever gained much traction, and gdb may not yet work well with
the result. When I was at HP, we considered implementing this scheme,
but found a couple of problems. In order for the per-header debug
information to truly be identical across compilations, the compiler is
obligated to output the debug info for all declarations in the header
file. Even though it may result in a significant space savings in the
final executable, it still results in a significant (and, in our
opinion, unacceptable) extra cost in the size of the relocatables. In
addition, #ifdefs within the header file often caused the information
to differ across compilations anyway, reducing the effectiveness of
the comdat elimination.

I also wrote a post-processing tool at HP (unfortunately never
open-sourced) to do the duplicate elimination. It's not the only one
of its kind out there, so that's clearly a viable solution, but it
does add extra time to the link step. I've also seen proposals to
integrate the post-processing step into the gold linker, but I'd
prefer an approach that lets the linker do the job using its existing
comdat processing ability.

-cary