Cross gcc Mailing List Archive
[Prev][Next][Index][Thread]

RE: Newlib's crt0.S

> I'm not sure if this will cause trouble, but is suspect its fine.

It depends on how the code is loaded.
 
> The ANSII spec says that uninitialised variables will be zero at startup. The

This is normally handled by the startup code (crt0) zeroing the 
BSS on standalone systems.  Other operating systems (eg. Unix) map
the BSS ZFOD
(zero-fill-on-demand), or zero the entire load area 
(eg. DOS).

> assumption for initialised variables is that the compiler will generate code
> that will initialise them before the main body of code is entered.

Again, this depends on your environment.  If your code is running
in RAM, then initialised globals will normally be in the data 
segment, and are thus implicitly initialised when the image is
loaded.

If you're running from ROM, the startup code may have to copy 
values from ROM to RAM.  (It's generally a pain in the rear to
relocate the data segment like this.)

> In the case
> of C++, there will be a list of constructors to call.

This is again handled by the startup code; the linker produces a list 
of global constructors which are processed before main() is called.

(Note that the above are based largely on using Gcc for embedded
development.)

I'm writing s/w for BCC 68332 board. So, there's no OS to initialise. During testing, my s/w will be downloaded into RAM. Finally, it will be ROMed. 

In all other cross compilers that I've used before, there is an option to compile for RAM or ROM. When compiled for ROM, the global variables initial values are created in a data space in ROM. Normally, this ROM's data is copied into the actual variable space in RAM in the C-startup code. Is this what is happening in gcc for embedded system? ( I didn't notice any ROM or RAM option in gcc). If so, how do I do the copying from ROM to RAM. I need to know the data segments name and size!

Thanks!
Follow-Ups:
Home | Subject Index | Thread Index