Reduce Dwarf Debug Size

Michael Eager
Sat Mar 3 04:17:00 GMT 2007

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.

I'm all in favor of reducing the size of DWARF data in executables,
but I don't think that this is the best approach.  This scheme
is reminiscent of similar problems related to C++ templates:
whether to generate code, where to generate it, and how to
manage generated code.  I think that this scheme has the same
problems which show up with template schemes which try to use
heuristics to determine when template code is generated.

While it may be common for "struct foo" to be defined in "foo.h"
and used in "foo.c", this is not the only time that a struct
is defined or used.  What if there is a "struct foo_helper" also
defined in "foo.h"?  Where is the debug info for this generated?
Is a file "foo_helper.c" required?

What happens if you compile "foo.c" without -g?  (For example,
if "foo.c" is in a library.)  If you have "bar.c", which includes
"foo.h", compiled with -g, gdb will not find a definition for
"struct foo".  I can imagine that the programmer would spend a
fair amount of time trying to figure out why adding '-g' to the
compiler command line or, more likely, to the invocation of
make, fails to work.  And, oddly enough, gdb would appear to
work for "bar.c", displaying source and most values, just not
letting the programmer display members of "struct foo".
(Consider the common case when "bar.c" is compiled as part of
a large project; determining that one of the many compiler
options is causing this strange behavior may take a while.)

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.

Michael Eager
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

More information about the Gcc-patches mailing list