This is the mail archive of the
mailing list for the libstdc++ project.
Re: Getting Apple's libstdc++ debug mode into the FSF tree
- From: Matt Austern <austern at apple dot com>
- To: snyder <snyder at fnal dot gov>
- Cc: Nathan Myers <ncm at cantrip dot org>, libstdc++ at gcc dot gnu dot org
- Date: Wed, 16 Jul 2003 22:55:50 -0700
- Subject: Re: Getting Apple's libstdc++ debug mode into the FSF tree
On Wednesday, July 16, 2003, at 10:06 PM, snyder wrote:
"Nathan" == Nathan Myers <firstname.lastname@example.org> writes:
Nathan> checking by default. Is there anybody reading who can say
Nathan> more about how/why the decision was made, and/or what it
Nathan> would take to get it revisited?
Well, i can say that we turned it off here because including the
concept checks increased the sizes of the object files by, IIRC,
~30% or so, due to the additional debugging information.
Now that the patch i submitted to eliminate unreferenced types from the
dwarf debugging output has gone into gcc, this problem should have
gone away (though i haven't actually tried turning concept checks
back on to verify it).
This seems to me like a big red flag. Do you know whether your
unreferenced-types flag applies to STABS as well as to Dwarf? If
not, I'd be nervous about the potential impact on .o sizes.
I'd like to do some tests. Some of Apple's customers are very
concerned about the sizes of executables when debugging is turned
on. (And if you think those concerns are silly, you should realize
that in some cases we're talking about sizes in the half-gigabyte
range.) If turning on concept checking has the potential to make
this worse, then I'd like to take a close look at it before making
it the default.
My suggestion: let's get Doug's changes in, and let's not tie them
to concept checking. Whether or not to turn on concept checking by
default is an orthogonal issue.