Re: [Mspgcc-users] .data initialization not working
On Mon, 8 Dec 2014 16:55:04 + (UTC) Grant Edwards wrote: > On 2014-12-08, Eric Price wrote: > > > to me the change to the TI linker scripts simply makes no sense > > None at all. It seems to be assuming that an MSP430 is running some > sort of OS with some sort of external non-volatile storage from which > it loads/runs programs. > That's the thing, not even that! Those linker files still store the actual program mashine code (.text segment) in non-volatile on-chip (flash)ROM - just the .data segment is loaded into volatile RAM - so even IF there was such an OS, it would still make no sense, as there's nothing gained by that even under that premise. -- Eric Price TTI GmbH - TGU Smartmote Pfaffenwaldring 4 D-70569 Stuttgart Tel.: +49 0711 - 6856 5369 Fax.: +49 0711 - 6856 6818 E-mail: pr...@smartmote.de Homepage: http://www.smartmote.de -- 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
Re: [Mspgcc-users] .data initialization not working
On 2014-12-08, Eric Price wrote: > to me the change to the TI linker scripts simply makes no sense None at all. It seems to be assuming that an MSP430 is running some sort of OS with some sort of external non-volatile storage from which it loads/runs programs. -- Grant Edwards grant.b.edwardsYow! Okay ... I'm going at home to write the "I HATE gmail.comRUBIK's CUBE HANDBOOK FOR DEAD CAT LOVERS" ... -- 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
Re: [Mspgcc-users] .data initialization not working
On 2014-12-08, Peter Bigot wrote: > Unfortunately this list doesn't support attachments. Perhaps somebody > could put it on E2E and add a pointer. > > Interesting that TI proposed a solution that doesn't work for ROM > resident applications, which are all but the most infinitesimal > subset of the applications that use an MSP430. (It's so implausible > I'm half convinced I don't understand exactly what's happened here.) I agree. This is completely baffling. Either somebody has incorrectly described what's going on, or we're all supposed to hook up disk-drives and blocks of SDRAM to our '430s and run some sort of OS on them. -- Grant Edwards grant.b.edwardsYow! I'm having a RELIGIOUS at EXPERIENCE ... and I don't gmail.comtake any DRUGS -- 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
Re: [Mspgcc-users] .data initialization not working
On 2014-12-08, Nicholas Clifton wrote: > 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. That makes no sense. Code is is flash. On startup, where is that 43 going be? If it's not in flash, where? > 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. That's how embedded microprocessors that run from flash _work_. > 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. So you're assuming that an MSP430 with a few KB of flash and a few hundred bytes of RAM is running some sort of OS that's going to load the program from disk into RAM and run it? > With this scenario there is no need to copy data between ROM and RAM > as the data is just loaded directly into RAM. By _WHAT_? -- Grant Edwards grant.b.edwardsYow! Life is a POPULARITY at CONTEST! I'm REFRESHINGLY gmail.comCANDID!! -- 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
Re: [Mspgcc-users] .data initialization not working
On Mon, 08 Dec 2014 14:33:15 + Nicholas Clifton wrote: > ... > 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. > The weird thing here is, that although the .data segment holding static initialization for global variables is being loaded into RAM (such implying some sort of external loading mechanism) the .text and .rodata segments containing program code and constants are still stored in the ROM segments. Having data in RAM would make sense under the premise that program code is also stored volatile and loaded into memory my means of a debugger, another program or other external means. (afaik one of the advertised features of the new toolchain version is execution from RAM on msp430, isn't it?) But since the default linker file still have their code in ROM that would mean 1 either the program is stored externally, but then it would have to flash/erase/overwrite the ROM section as well as copy its initialization data to RAM in order to execute - that makes no sense 2 or the program is stored in ROM to begin with, but then it needs to magically have its RAM contents appear out of thin air after any sort of reset - that also makes no sense 3 or its simply silently assumed that static initialization of global variables is an unneeded feature no longer supported by msp430gcc - but even then the compiler would have to at least issue a warning whenever it encounters a thus rendered non-functional static variable assignment and not silently ignore it which causes countless of existing embedded applications to show undetermined behavior when executed to me the change to the TI linker scripts simply makes no sense cheers Eric -- Eric Price TTI GmbH - TGU Smartmote Pfaffenwaldring 4 D-70569 Stuttgart Tel.: +49 0711 - 6856 5369 Fax.: +49 0711 - 6856 6818 E-mail: pr...@smartmote.de Homepage: http://www.smartmote.de -- 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
Re: [Mspgcc-users] .data initialization not working
On Mon, Dec 8, 2014 at 9:01 AM, Paul Sokolovsky wrote: > Hello, > > On Mon, 8 Dec 2014 08:42:28 -0600 > Peter Bigot wrote: > > > Unfortunately this list doesn't support attachments. Perhaps somebody > > could put it on E2E and add a pointer. > > Or maybe RedHat even has version control system, maybe even with web > interface? > > > > > Interesting that TI proposed a solution that doesn't work for ROM > > resident applications, which are all but the most infinitesimal > > subset of the applications that use an MSP430. (It's so implausible > > I'm half convinced I don't understand exactly what's happened here.) > > Peter, can you please consider maintaining mspgcc for couple years > more, while dear esteemed vendors sort out issue how to teleport > application code out of thin air into RAM? > Unfortunately, no. I switched all my development machines to Ubuntu 14.04 this weekend, and mspgcc won't build because it uses outdated binutils and gcc sources. I backported some of the changes, but the host gcc ICEs on a gcc 4.7.2 source file not obviously related to msp430. So that's the end of that. It'd probably be pretty easy to fork my msp430-elf repository and upstream gcc and fix about half the issues we're discussing, but I'm irritated enough with how TI's managing the MSP430 product line these days that I'm not really motivated to keep trying to bail them out. More importantly, I've found an interesting position that actually pays me for what I can do, so I really need to focus on that. There we're using ARM chips; much nicer. Peter (going back to work now) -- 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
Re: [Mspgcc-users] .data initialization not working
Hello, On Mon, 8 Dec 2014 08:42:28 -0600 Peter Bigot wrote: > Unfortunately this list doesn't support attachments. Perhaps somebody > could put it on E2E and add a pointer. Or maybe RedHat even has version control system, maybe even with web interface? > > Interesting that TI proposed a solution that doesn't work for ROM > resident applications, which are all but the most infinitesimal > subset of the applications that use an MSP430. (It's so implausible > I'm half convinced I don't understand exactly what's happened here.) Peter, can you please consider maintaining mspgcc for couple years more, while dear esteemed vendors sort out issue how to teleport application code out of thin air into RAM? > > Peter > > On Mon, Dec 8, 2014 at 8:36 AM, Nicholas Clifton > wrote: > > > Hi Guys, > > > > I have attached a patch which will restore the old "movedata" > >> functionality to the toolchain. > >> > > > > Strange - the attachment disappeared. Here it is again. > > > > Cheers > > Nick > > > > > > > > -- > > 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 > > > > -- Best regards, Paul mailto:pmis...@gmail.com -- 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
Re: [Mspgcc-users] .data initialization not working
Unfortunately this list doesn't support attachments. Perhaps somebody could put it on E2E and add a pointer. Interesting that TI proposed a solution that doesn't work for ROM resident applications, which are all but the most infinitesimal subset of the applications that use an MSP430. (It's so implausible I'm half convinced I don't understand exactly what's happened here.) Peter On Mon, Dec 8, 2014 at 8:36 AM, Nicholas Clifton wrote: > Hi Guys, > > I have attached a patch which will restore the old "movedata" >> functionality to the toolchain. >> > > Strange - the attachment disappeared. Here it is again. > > Cheers > Nick > > > > -- > 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 > > -- 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
Re: [Mspgcc-users] .data initialization not working
Hi Guys, I have attached a patch which will restore the old "movedata" functionality to the toolchain. Strange - the attachment disappeared. Here it is again. Cheers Nick -- 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
Re: [Mspgcc-users] .data initialization not working
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 ? Cheers Nick -- 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
Re: [Mspgcc-users] .data initialization not working
Hi Guys, I have attached a patch which will restore the old "movedata" functionality to the toolchain. It updates the assembler and the crt0 code so you will need to recompile and relink any binaries that were causing you problems. Note - this patch does not move the .data section back into ROM. We are going to have to see how TI want to address that issue. It does however include a couple of comments in the libgloss/msp430/msp430xl-sim.ld linker script that show what needs to be done if you did want data to be placed in ROM. Cheers Nick -- 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
Re: [Mspgcc-users] .data initialization not working
Hi,
I found a workaround for the .data initialization problem
that does not require a custom patch to the compiler.
1. Change the linker scripts back like they were in the old compiler -
to place .data initialization in ROM, and runtime data in RAM
example:
>
--- msp430f5437a.ld.ram 2014-12-05 15:28:35.0 +0100
+++ msp430f5437a.ld.rom 2014-12-05 14:06:31.0 +0100
@@ -265,11 +265,11 @@
. = ALIGN(2);
_edata = .;
PROVIDE (edata = .);
PROVIDE (__dataend = .);
- } > RAM
+ } > RAM AT > ROM
/* Note that crt0 assumes this is a multiple of two; all the
start/stop symbols are also assumed word-aligned. */
PROVIDE(__romdatastart = LOADADDR(.data));
PROVIDE (__romdatacopysize = SIZEOF(.data));
>
2. Luckily the symbols __datastart and __romdatastart are still
present in the ld templates, only the crt0 code to copy over
data from ROM to RAM is no longer there. This can be worked around with
the following stand alone C code:
copydata.c
> #include
> #include
>
> extern char __datastart;
> extern char __romdatastart;
> extern char __romdatacopysize;
> static void* const datastart=&__datastart;
> static void* const romdatastart=&__romdatastart;
> static uint16_t const romdatacopysize=(uint16_t)&__romdatacopysize;
>
> __attribute__((constructor)) void __data_move() {
> if (datastart!=romdatastart) {
> memmove(datastart,romdatastart,romdatacopysize);
> }
> }
this does not require changes to existing programs per se, as that code
can be compiled separately and linked together with any existing or
even precompiled code to get the desired result, as crt0 will call the
__attribute__((constructor)) function before it calls main()
cheers
Eric
--
Eric Price
TTI GmbH - TGU Smartmote
Pfaffenwaldring 4
D-70569 Stuttgart
Tel.: +49 0711 - 6856 5369
Fax.: +49 0711 - 6856 6818
E-mail: pr...@smartmote.de
Homepage: http://www.smartmote.de
--
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
Re: [Mspgcc-users] .data initialization not working
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 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
Re: [Mspgcc-users] .data initialization not working
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. :-) Cheers Nick -- 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
Re: [Mspgcc-users] .data initialization not working
This is a place to report these; other places would be the TI forums; see
http://e2e.ti.com/support/development_tools/compiler/f/343/t/384148
It'd help if you provide a standalone program with the sort of
initialization expressions that aren't working for you, along with the
exact command line you're using. From my experience, global variables with
initializers are constructed properly. (Note that if you use -minrt you
are telling the compiler/linker to strip out the static initialization
routines. Generally not a good idea.)
Peter
On Sat, Dec 6, 2014 at 5:03 PM, Olivier Girard wrote:
> Hi all,
>
> I just want to start a new thread regarding another issue I mentioned in an
> earlier mail.
>
> 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.
>
> After looking around in the crt* sources, I noticed there is a procedure
> meant to do that in the "msp430-elf/tools/libgloss/msp430/crt_movedata.S"
> file.
> When compiling my program using the standard linker scripts provided with
> the toolchain, I can't see this procedure anywhere in the linked
> executable.
>
> I was not able to see if the problem lays in the linker script itself or in
> the compiled crt0 procedures.
> However, I can restore the proper functionality by re-writing the
> crt_movedata procedure directly in my C code and calling it first thing
> when entering the main():
>
> "...
> extern const unsigned char * __datastart;
> extern const unsigned char * __romdatastart;
> extern const unsigned int__romdatacopysize;
>
> void my_crt_movedata(void) {
> __asm__ __volatile__(
> "mov #__datastart, R12 \n\t"
> "mov #__romdatastart,R13 \n\t"
> "mov #__romdatacopysize, R14 \n\t"
> "call #memmove"
> );
> }
>
> int main(void) {
>
> my_crt_movedata();
>
> WDTCTL = WDTPW | WDTHOLD; // Disable watchdog timer
> ..."
>
> As this solution is definitely not acceptable, does someone has an idea
> about what currently goes wrong in the current toolchain release (crt ?
> linker script ? ...).
>
> Is this mailing list also the right place to report this kind of issues ?
>
> Thanks a lot,
> Olivier
>
> PS: currently running:
> msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-98)) (GNUPro
> 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)
>
>
> --
> 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
>
>
--
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
