This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Huge Increase in Unstripped Executable Size G++ 2.95 to 3.2
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:
> > I didn't get comments on the last version of the
> > -feliminate-unused-dwarf2-types patch that i posted.
>
> Sorry for not following up.
>
> > This patch makes no changes in the gcc testsuite results, even
> > if i change the default for the switch to 1. 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.
I don't see a problem with adding a reference to the type in question.
Go ahead and do this and we'll fix up the testsuite next time someone
tests with GCC HEAD.
I don't see a big issue with leaving out unused types from the GDB
side.
> > There were a couple comments about the option name: that maybe
> > it should be something like -feliminate-unused-debug-types,
>
> I do think this sounds better.
>
> > 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.
>
> I'm not really worried about this though, since I'm not really
> a fan of our current duplicate header removal code though;
> compare-by-hash is fundamentally flawed.
>
> I'll bootstrap your patch, change the name of the option, and
> apply it as-is, i.e. disabled by default. We can address the
> other issues raised as a followup.
Should we also persue this for 3.3? It's not strictly speaking a
regression, except in that "this worked in stabs" sense.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer