Reduce Dwarf Debug Size

Lawrence Crowl crowl@google.com
Thu Mar 1 21:07:00 GMT 2007


Andrew Pinski <pinskia@gmail.com>
> How does it interact with  -femit-class-debug-always?

The new option is a filter on dwarf emission, and so it applies
after this option.

> Also can you rename the option to something like:
> -femit-struct-debug[=spec-list].  To me a -gstruct option means
> there is a debugging type named struct which is not the case as
> the type is still dwarf2/3.

Sure.

> Also one more thing, can you please write that as DWARF 2, even
> though DWARF 1 support was removed from GCC, it is always good to
> know which version of DWARF you are talking about.

Sure.

Mike Stump <mrs@apple.com>
> I have a counter proposal, instead, use -frepo to select where
> you want to lay down the debug information.

Ian Lance Taylor <iant@google.com>
> -frepo is fragile for large projects, and it affects much more
> than debug information.  I don't think it is a real alternative.

Given the large project problem, I would rather not persue -frepo.

Daniel Jacobowitz <drow@false.org>
> I realize a lot of work went into this patch, and I do appreciate
> Lawrence working on this hard problem; but I think yet another
> (our third or maybe fourth) option to omit a specific set of debug
> info is the exactly wrong solution.

A more comprehensive solution would be better.  I am the first
to admit that my patch is not a final solution.  However, the
comprehensive patches are not available, and hence are solving
no problems.  This patch does solve significant problems today.
Think of the patch as buying time for the better solution.

Ian Lance Taylor <iant@google.com>
> Lawrence's patch is a much smaller and simpler change than a
> symbol database.  It requires no significant change to existing
> build systems.

Daniel Jacobowitz <drow@false.org>
> It's simpler, yet the option involves a specification list and two
> full pages of documentation which I read twice and still couldn't
> figure out when I'd supply which.  It's an optional knob with a
> lot of complexity.

You are reading ahead of your needs.  For most people, there are
only three spellings that you need to worry about.

    <no option>    nothing different
    -gstruct       save a bunch of space, little impact on debugging
    -gstruct=base  save more space, but more impact on debugging

The rest of the specification exists because the simple-to-use
"-gstruct" has a complicated specification and people with problems
might want access to the mechanisms needed to implement the plain
version.

> And it relies on source naming conventions, which in my humble
> opinion is a pretty gross thing for GCC to be doing.

Andrew Pinski <pinskia@gmail.com>
> It forces a naming convention on people.  Even there are cases where
> classes are always in the headers and there is no corresponding
> source file to them.

I would characterize it as exploiting a naming convention that is
used by nearly all programmers.  The option doesn't help you if your
naming convention doesn't match.  Just as importantly, the option
doesn't hurt doesn't hurt because if you don't ask for the option,
nothing changes.

Mike Stump <mrs@apple.com>
> I just worry that it works fine for all sample programs 500 lines or
> less and on nothing larger.  I'd rather have a real user evaluate
> it in the context of a use pattern and tell us now it performs
> for them.

The motivation and experiments for this option were very large
applications.  Small applications don't need the option because
the amount of space you save isn't work worrying about.

Ian Lance Taylor <iant@google.com>
> Lawrence has already evaluated it on Google's internal codebase,
> which is more than 500 lines.  Lawrence, could you send out the
> various tables showing the percentage reductions for the various
> options?

Actually, I did this in the original email.  Here it is for a
very large application.

 debug executable
  size   size
  100%   100%   with only -g
   60%    73%   with -g -gstruct
   37%    58%   with -g -gstruct=base

So in rough numbers, the option buys you a factor of 2.5 in debug
size and a factor of 1.7 in executable size (because the debug size
is a large fraction of the executable size).

Mike Stump <mrs@apple.com>
> In the various scheme we've done, and we've done a few, leaving
> the debugging information in the .o files and having a utility
> to boost them out and save them, if you need to do that, is the
> current winner.

Ian Lance Taylor <iant@google.com>
> That approach doesn't work well for us because it requires you to
> keep the .o files around if you want to do any debugging.

Just as importantly, the .o files themselves take more space.  In a
distcc environment, excess .o size translates to higher bandwidth
requirements and more delay.

Daniel Jacobowitz <drow@false.org>
> If there is a general consensus that the approach is OK, then I
> would recommend removing most of the optional combinations.  I bet
> you can find a maximum of three clearly increasing levels that
> work for the vast majority of people for whom it is useful at all.

I identified those levels earlier.  Would it be sufficient to
reorient the documentation to focus on those levels and leave the
detailed specification to later?


So, these are my action items, unless I hear otherwise.

(1) Change the option name to -femit-struct-debug[=spec-list].
(2) Rewrite the documentation to focus on the primary use cases.

Amendments?

-- 
Lawrence Crowl



More information about the Gcc-patches mailing list