Mail Archives: djgpp-workers/1998/05/21/03:43:20
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.
---------- Forwarded message ----------
Date: Wed, 20 May 1998 13:17:03 GMT
From: Troy <reply AT newsgroups DOT com DOT ok>
To: djgpp AT delorie DOT com
Newgroups: comp.os.msdos.djgpp
Subject: Re: gcc 2.8.1 outputs are much larger than gcc 2.7.2 ... why ??
David Vrabel <d DOT vrabel AT n-shropshire DOT ac DOT uk> wrote in article
<35628954 DOT 480044 AT 192 DOT 168 DOT 1 DOT 250>...
> "Tony Kao" <MacGyver AT ms11 DOT accmail DOT com DOT tw> wrote:
>
> >#include <iostream.h>
> A minor point: Use <iostream> as the ANSI standard headers no longer
> have .h at the end.
>
> >I found the execution file size is 386560 bytes, which is much bigger
than
> >gcc 2.7.2 outputs. For gcc 2.7.2 the execution file size for the same
> >program is 187675 bytes.
> Just a guess: Could it be the exception handling tables? Try
> -fno-exceptions.
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.
Troy Van Horn
- Raw text -