Re: Static Objects in the .data section.

[Michael Beach <mbeach@awa.com.au>]

> > Hello
> > 
> > I am porting a fair amount of C++ code which has static objects through
> > it from an old MRI compiler to gcc.
> > 
> > The target is m68k-coff, and the versions are gcc-2.7.2, and
> > binutils-2.7. 
> > I have noticed that the compiler puts the static objects in the '.data'
> > section. This is causing problems as I am required to now provide space
> > in the ROM for these objects which are full of zeros. Added to this one
> > object has a very large array for network buffers and does not fit.
> > Downloading over a serial link to a target is out of the question.
> > 
> > I am puzzled why the C++ part of gcc puts static objects, and
> > uninitialised variables into the '.data' section. The C part of the
> > compiler put uninitialised variables in '.comm'.
> > 
> > I found the '-fconserve-space' option which forces the variables into the
> > '.comm' section. This means the linker will not generate an error if the
> > object is declared in more than one file.
> > 
> > The price is ok for an application on a host computer where the cost of
> > disk space is cheap, how-ever it seems a heavy price to pay in an
> > embedded system. 
> > I have not found any doco on the '-fconserve-space' option. I found it in
> > the source code. Does anyone know if it is going to stay ?
> 
> > Does anyone have a better idea about getting the objects in the common of
> > '.bss' section ?
> 
> One way is to use link editor scripts, by which you can state that various 
> COFF sections of the code is going to be placed at link editor segments
> such  as .data, .comm etc. It gives greater flexibility, but the problem
> may be to  declare arbitrary COFF sections in C++ if this is necessary.
> 

This is not a solution in this case, because the compiler, without
-fconserve-space, puts the unintialized objects in file scope into the .data
section (we observed this by looking in the .s file). Using a linker script to
put .data into .bss is being a bit too cunning for ones own good...

> /Jonas Mellin
> 

Regards
M.Beach