obscure/excessive stabs entries
Matthew Liberty
matt@CadMOS.COM
Fri Jul 21 15:30:00 GMT 2000
Hi,
I am running gcc 2.95.2 on Solaris 2.7. What I am reporting is not
strictly a bug but rather an efficiency issue.
While I have attached the cpp output as requested, here is the main
program in full:
#include <vector.h>
typedef vector<void*> myvec;
//
#if 1
typedef myvec::iterator iptr;
#endif
I am compiling with -g and find the size of the .o varies strongly with
the inclusion/exclusion of the #if'ed section. If I compile
"g++ -c -g delay_tcl.cxx -o foobar.o" I get:
-rw-r--r-- 1 matt users 30036 Jul 21 10:04 foobar.o
However if I change "#if 1" to "#if 0" I recompile I get:
-rw-r--r-- 1 matt users 25696 Jul 21 10:04 foobar.o
That tells me the one added typedef adds 4340 bytes to my .o! Note that
I haven't even used the typedef, only declared it. Now in my real
application I have quite a few similar typedefs in a very commonly
included header file. This means about 200K in every .o and there are
many of them. The final binary when loaded into gdb winds up pushing
the process size way up.
I dug into the a bit and see if I compile with -save-temps and diff the
.s files (#if 1 or 0) that the differences are some very obscure stabs
entries. I've attached them (stabs_info). I can see no use to these
entries but they are verbose and seem to be copied nearly verbatim into
the .o (I looked with hexl-mode).
Is there any more optimal way to handle this? In general I am not
interested in recording data related to the allocator types so perhaps
it could be optional.
many thanks
-Matt Liberty
More information about the Gcc-bugs
mailing list