Re: Huge Increase in Unstripped Executable Size G++ 2.95 to 3.2

[Jason Molenda <jason-gcclist at molenda dot com>]

(about the -feliminate-unused-dwarf2-types patch)

We have a patch to gcc in use at Apple to do the same with stabs,
it's been the default for a while with our gcc.  We've found it to
be a pretty effective optimization when faced with very large header
files.  We had a lot of problems getting all the bugs worked out
with stabs and gnarly C++ programs, but I expect most of those
problems stem from the nature of stabs itself.

On Fri, Feb 28, 2003 at 03:03:16PM -0800, Richard Henderson wrote:

> On Fri, Feb 28, 2003 at 03:55:59PM -0600, snyder wrote:

> It causes one failure
> > in the gdb test suite, where the test was asking for information
> > about a type that was declared but not used.
> 
> If we can come to an arrangement with the gdb folk regarding
> their testsuite, I think it would be useful to have this 
> default to 1.

The Apple "-gused" implementation has a similar limitation.  It
does introduce a small change in behavior; people writing little
test programs with unused variables like

foo () {
  int a;
  puts ("not using a");
}

If they break in foo and try to examine a, it won't have any debug
info so they'll get a "variable not found" type error.  In practice,
this only comes up on tiny little test programs that people write by
hand for some odd reason or another.

> > A caveat is that this may not interact well with the mechanism for
> > dwarf2 duplicate removal.  As i understand how that works, it relies
> > on a given header file generating the same debugging information,
> > regardless of what compilation unit it is included into.  This
> > patch will invalidate that assumption.
> 
> Well, that could be delt with, possibly by turning off
> -feliminate-unused-debug-types when -feliminate-dwarf2-dups
> is enabled.  Or possibly by arranging for stuff mentioned
> from non-default dwarf2 sections to be marked.

At Apple we are trying to address this with the "Saucer Separation"
that Devang has posted on a few times -- emit the full debug info
for your header files in a single debug-.o-file (built like you
would a precompiled header file, at the start of compilation), and
all objfiles include references to that debug-.o-file's debug
entries.  The linker combines them all into an executable and gdb
can't tell what was going on during compilation.

Anyway, it's the idea we came across for this very problem.

J