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?
What you wrote seems to imply this, and it matches what Olivier's reported,
but not what I've experienced.
It's also a clear violation of the C language required behavior, which TI
has been known to do in their own compiler in pre-elf linker days.
(
Peter
On Mon, Dec 8, 2014 at 5:55 AM, Nicholas Clifton <ni...@redhat.com> wrote:
> 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.
>
I'm curious how the linker can place initialized data into RAM on a device
and have it work after a power-cycle. 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 that its initialization has
been removed so the value of myvar when main starts is not 43?
What you wrote seems to imply this, and it matches what Olivier's reported,
but not what I've experienced.
It's also a clear violation of the behavior required by the C language,
which TI has been known to ignore in their own compiler in pre-elf linker
days when we could not trust that a variable defined by:
int myzero;
would have a zero value when main started.
> 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.
>
This seems to be redundant with -fcode-sections -fdata-sections
-Wl,-gc-sections. What was the argument for using a more complex solution?
>
> 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. :-)
>
Thanks for your efforts.
Peter
------------------------------------------------------------------------------
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
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
