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