Static Objects in the .data section.
Fri May 23 04:13:00 GMT 1997
> 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.
More information about the crossgcc