Hi Peter,

> Nick: Are you saying that the linker scripts are changing so that a global
> variable definition like this:
> int myvar = 43;
> will result in myvar being stored in RAM, and no initialization of it so
> the value of myvar when main starts is not 43?

No.  I am saying that myvar will be stored in the .data section of the
executable image and that its value in this image, will be set to 43. 
In addition the section header for the .data section will be set to an 
address in RAM, so that when the executable is loaded into the MCU's 
memory the correctly initialised variable will be ready to be used.

What has changed is the presumption of where the executable is stored 
before it starts executing.  Previously there was an implicit assumption 
that the executable would be stored in the ROM of the system and that at 
program startup there would have to be an explicit copying of data from 
the ROM image into RAM.  With the current linker scripts there is an 
assumption that the executable is stored externally, and it is brought 
into system memory before execution begins.  With this scenario there is 
no need to copy data between ROM and RAM as the data is just loaded 
directly into RAM.

It appears however that what we need to do is to support both scenarios. 
  I have sent a patch to this list which does most of the work - fixing 
the assembler and the crt0 startup code.  What is missing is a new set 
of linker scripts, explicitly designed for ROM-resident executables.  I 
am not sure what the best solution here will be, and I
am going to wait for some guidance from TI before proceeding.  There are 
already per-MCU linker scripts.  Maybe there needs to be two sorts per MCU ?


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