Hi Olivier,

> When porting some programs to the latest MSPGCC version from RedHat/TI, I
> noticed that ALL initialized global variables in my C code are not
> initialized by the crt0 code.

Are you using your own linker script or a linker script from an older 
release ?

The problem is that MSP430 linker scripts used to place the .data 
section into the ROM memory region and then code in crt0.o would copy 
the data into RAM at program startup.  Newer linker scripts place the 
.data section directly into the RAM or HIFRAM memory regions, so no 
copying is needed.

A second part of this problem is that an optimization was added to help 
reduce the size of the startup code for small programs.  The code in 
crt0.o was split up into small files and crt0.o was then converted into 
a library.  When an application is linked against the crt0 library only 
the pieces of startup code that it really needed would be brought into 
the executable.  Thus for example if a program never returned from 
main() then crt0 code to call exit() after main is not needed and so all 
of the cleanup code in the C library could be left out.

In order for this optimization to work however, the cooperation of the 
compiler and assembler are needed.  They are expected to create 
unresolved references to special symbols whenever they detect that a 
certain feature of crt0 will be needed.  So for example the compiler 
creates a reference to __crt0_call_exit if it compiles a function called 
"main" that has an execution path that leads to the function returning.

One of the parts of crt0 that can be omitted is (or rather was) the 
copying of data from ROM to RAM.  The need for this part of crt0 was 
detected by the assembler where it would create a special symbol 
__crt0_movedata whenever the .data section was used.  As part of a 
ratification of linker scripts however the decision was made to move 
.data into RAM and so the crt0 library and the assembler were updated to 
remove the use of the __crt0_movedata symbol.

So ... you have three options:

   1. Stick with your solution of adding (back) the movedata function. 
You may want to add code to skip calling memmove if __datastart == 
__romdatastart since memmove does not cope with this situation.

   2. Change your linker script to place the .data section into RAM. 
Note - you will also want to make sure that the .upper.data and 
.lower.data sections are also placed into RAM.

   3. Complain to TI that you want the movedata functionality restored 
and they will fix it.  (Well I assume that they will.  Probably by 
asking me to do it. :-)


Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
Mspgcc-users mailing list

Reply via email to