Mail Archives: djgpp-workers/1998/05/21/09:31:08
Date sent: Thu, 21 May 1998 10:42:47 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Andris Pavenis <pavenis AT lanet DOT lv>, Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Copies to: djgpp-workers AT delorie DOT com
Subject: Re: gcc 2.8.1 outputs are much larger than gcc 2.7.2 ... why ?? (fwd)
> Is the claim in the message below true? Are GCC and Binutils configured
> inconsistently as far as the local labels are concerned?
>
> If so, I think this should be corrected.
>
Info file about AS tells that unless special command line option is specified
AS does not include local labels (that begins with 'L') in symbol tables.
However this behaviour can be overriden by target configuration.
However it looks that these labels stays in object files for both gcc-2.7.2.1
and gcc-2.8.1.
Enabling exceptions of course makes object files (for C++) bigger. Without
exceptions there were no significant changes in size of object files between
gcc-2.7.2.1 and 2.8.1.
There is one more problem. I did not suceed to get rid of local labels in
libstdcxx.a and libgpp.a (I compiled without debugging information).
That perhaps could be one of the sources of huge executables we'll getting
with gcc-2.8.1 (2.7.2.1 used other version of libstdc++ which as I tested
does not contain info about local labels)
I think, that one of possible sources of this problem can be some changes
between binutils-2.7 and binutils-2.8 (I used the latest, but haven't tested with
2.7)
> It's partly the exception tables. The reason the file size is larger
> is that when gcc 2.8.1 produces code with exception tables, it produces a
> lot of labels in the assembly file it outputs (run gcc -S program.cc to see
> for your self). All these lables are local labels and begin with a capital
> 'L'. AS.exe from binutils 2.8.1 expects local labels (labels which don't
> need to be in the symbol tables) to begin with '.L'. Because of the
> missmatch, the symbol table explodes in size with all these useless labels
> when you are compiling C++ code with exceptions enabled. A partial
> sollution is, if you don't need exception handling, to compile with
> -fno-exceptions, and make sure you strip your final executables.
>
> The real solution for this is to get bintuils and gcc on the same
> wavelength. Either recompiling binutils after making a fairly simple
> change to a header file somewhere, or recompiling gcc getting it to produce
> the proper form of local labels.
>
Tried to do something with gcc and didn't suceed. After that I saw that the
format of the names of local lables is identical to one of gcc-2.8.1 I can
only think that the problem is in binutils.
Andris
- Raw text -