Code Bloat g++
Thu Feb 17 16:02:00 GMT 2000
[ bloated debuf information ]
> That assumes that large debug information is redundant to a ridiculous
> degree. I don't know whether this is the case, but until I'm proven
> wrong, I'd always assume that every single bit in the debug
> information serves a purpose.
It seems that you must not be a C++ developer (meaning: someone who works
on large programs in C++ with hundreds of .o files linked together). This
is one of the things we suffer from with a C++ compiler that is written in
C; the maintainers don't experience the compiler's deficiencies in the
same direct way as for the C compiler (the compiler at least has to
> With that assumption, it is ok for me if debug information is large -
> because it could not be much smaller.
I've repeatedly (over the 10 years I've been using g++ -- I first used it
in January 1990) gotten the g++ developers to back out changes that
accidentally tripled the size of the debug information (usually by
adding redundancy by emitting all the debug information in every .o
file in response to a complaint from someone that they couldn't see
There are a number of sources of redundancy. The basic issue is that many
.o files include the same classes and thus have redundant debug
information. Yes, the linker can eliminate duplicates, but all those .o
files have to be generated, processed by the linker, and transferred
across the network.
Of course squangling is a big win and I'm looking forward to the day that
we can turn that on by default.
One way to think of how to handle this is to use similar techniques that
are used to avoid redundant virtual function tables: generate the detailed
debug information for a class only in the .o file that implements the
first non-inlined, virtual method. g++ already does some tricks like
that. But that doesn't help with STL debug symbols since those classes
> > Cool optimizations are sexier, but in real life developers will be
> > doing a lot more compiles with -g than with -O.
> Real life debuggers also have large disk space and incremental linkers
Those help, but can be insufficient when compiler developers who don't
think about the issue for 2 gigabytes of virtual memory to do a link, and
dozens of gigabytes to store all the .o files. The first thing that dies
is the network. (no, g++ is not that bad. Sun C++ 5.0 *is* that bad. It
seems that we need user pressure, from folks like me and Gerald, to keep
g++ from getting that bad).
More information about the Gcc