This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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 ? Chris Johns Networks Plessey Asia Pacific Pty Ltd