Reduce Dwarf Debug Size

Daniel Berlin
Sat Mar 3 22:33:00 GMT 2007

On 3/2/07, Michael Eager <> wrote:
> Lawrence Crowl wrote:
> > A major contribution to object and executable size is DWARF debug
> > information size.  A major contribution to debug information
> > size is struct descriptions replicated in several object files.
> > This patch adds an option to reduce the size of this information,
> > which mainly benefits C++.
> >
> > The basic idea is to not emit struct debugging information in the
> > current compilation unit when that information will be generated
> > by another compilation unit.  The primary criteria is whether the
> > base name of the file containing the struct definition matches the
> > base name of the main file being compiled.  For example, if struct
> > foo is defined in bar.h, then when used in bar.c, the compiler will
> > generate the struct debugging information.  On the other hand, when
> > used in ping.c, the compiler will not generate the information.
> > This simple approach is complicated by templates, system headers,
> > indirect use of structs, etc.
> If the problem is multiple copies of DWARF data included in
> executables, I think that the solution for this lies in having
> the linker eliminating duplicate definitions.  Another way
> to address this is to have the executable contain references
> to the object files and read debug data from there as needed.
> I believe that the DWARF Committee will be considering a
> proposal to that effect.

Everyone is always in favor of the linker approach (or a symbol
database, or any other myriad of better solutions), but
1. Reading in and duplicate eliminating gigabytes of debug info is no
picnic in the linker either.
and more importantly
2. People have been talking about doing duplicate DWARF2 elimination
in ld for 5+years now, and it hasn't gotten done.  It's just very hard
to do in the current linker.

Whenever someone comes up with a working patch that actually helps
with the problem for some significant class of users, there are always
objections that it could be done better.
This is almost always true.
However, unlike most patches of this nature (helping some subset of
users), this patch
1. Makes it neither harder nor easier to do something better (which is
usually not true of most other not-best-solution patches)
2. Is not large enough to be a real maintenance burden
3. Has been tested and shown to work well for at least one very large codebase.

If you want to go implement DWARF2 elimination in ld, patches are of
course welcome.
In the meantime, I agree with Ian that we should consider this one, as
I don't see the harm.

More information about the Gcc-patches mailing list