This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Executable has doubled in size!


> From: wayne_thomson@agilent.com
> To: gcc@gnu.org
> Cc: simon_love@agilent.com, helena_garry@agilent.com
> Date: Thu, 27 Jun 2002 08:48:26 +0200

> After some investigation, I realised that the size difference is the
> result of where the global variables have been placed.  For the I960
> compilation, they have been placed in the data segment:

> text    data    bss     dec     hex     filename
> 236     267812  2       268050  41712   i7599_e4254a.o

> but the Strong Arm compilation has placed the global data in the bss segment:

> text    data    bss     dec     hex     filename
> 272     4       259844  260120  3f818   i7599_e7568a.o

> Why the difference between the two versions of gcc?

Older compilers used to put uninitialized data in the .data segment,
newer ones put them in the .bss segment for g++.  Older compilers
didn't have anyway internally within the compiler to express the right
concepts, as in C++, you want link errors for dups, and commons don't
give errors.

> Is there an option to force the uninitialised global data into the
> bss section for the I960 compilation?

>From your manual:

@item -fconserve-space
Put uninitialized or runtime-initialized global variables into the
common segment, as C does.  This saves space in the executable at the
cost of not diagnosing duplicate definitions.  If you compile with this
flag and your program mysteriously crashes after @code{main()} has
completed, you may have an object that is being destroyed twice because
two definitions were merged.

-fconserve-space is the option you seek.

> Is the behaviour of g++ different for varying architectures?

Yes.

> I've tried the "-fno-common" option with no effect.

-fcommon would be the one, but that is the default.  This
(-fno-common) has more an effect for C and only makes them bigger
(common -> data), not quite what you wanted.

> Any help/guidance would be appreciated - the eventual size of our
> code is important.

Well, these option don't change the size of your code.  Neither do
they change the size of the data segment when running.  They reduce
disk space to store your objects, that's about it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]