.data initialization not working

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

.data initialization not working

Olivier Girard
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Peter Bigot-4
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

nick clifton
In reply to this post by Olivier Girard
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Peter Bigot-4
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Eric Price
In reply to this post by Olivier Girard

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:

> <snip>
--- msp430f5437a.ld.ram 2014-12-05 15:28:35.000000000 +0100
+++ msp430f5437a.ld.rom 2014-12-05 14:06:31.000000000 +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));
> </snip>

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 <stdint.h>
> #include <string.h>
>
> 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: [hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

nick clifton
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

nick clifton
In reply to this post by Peter Bigot-4
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

nick clifton
In reply to this post by nick clifton
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Peter Bigot-4
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Paul Sokolovsky
Hello,

On Mon, 8 Dec 2014 08:42:28 -0600
Peter Bigot <[hidden email]> 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 <[hidden email]>
> 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
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
> >



--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Peter Bigot-4
On Mon, Dec 8, 2014 at 9:01 AM, Paul Sokolovsky <[hidden email]> wrote:

> Hello,
>
> On Mon, 8 Dec 2014 08:42:28 -0600
> Peter Bigot <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Eric Price
In reply to this post by nick clifton
On Mon, 08 Dec 2014 14:33:15 +0000
Nicholas Clifton <[hidden email]> 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: [hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Grant Edwards-6
In reply to this post by nick clifton
On 2014-12-08, Nicholas Clifton <[hidden email]> 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.edwards        Yow! Life is a POPULARITY
                                  at               CONTEST!  I'm REFRESHINGLY
                              gmail.com            CANDID!!


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Grant Edwards-6
In reply to this post by nick clifton
On 2014-12-08, Eric Price <[hidden email]> 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.edwards        Yow! Okay ... I'm going
                                  at               home to write the "I HATE
                              gmail.com            RUBIK'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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Grant Edwards-6
In reply to this post by Peter Bigot-4
On 2014-12-08, Peter Bigot <[hidden email]> 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.edwards        Yow! I'm having a RELIGIOUS
                                  at               EXPERIENCE ... and I don't
                              gmail.com            take 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: .data initialization not working

Eric Price
In reply to this post by Grant Edwards-6
On Mon, 8 Dec 2014 16:55:04 +0000 (UTC)
Grant Edwards <[hidden email]> wrote:

> On 2014-12-08, Eric Price <[hidden email]> 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: [hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users