Yes, the new mspgcc4 solves the problem! It tried my test code and everything works as expected. Also tried my full application code with both -O0 and -O3 and it works. Yahoo!!!
Thanks, Carl p.s. On my Fedora 9 and Ubuntu 9.10 machines the /buildgcc.pl fails with the following: Failed to execute sh do-gcc.sh "/opt/msp430-gcc-4.4.3" "4.4.3" "http://ftp.uni-kl.de"; "build" "gcc-4.x" "4.3.1" "2.4.1" at ./buildgcc.pl line 237, <STDIN> line 9. Despite the message I didn't notice any errors so I modified the /buildgcc.pl line 237 to not die and to continue with other commands. It then seemed to install mspgcc4 fine. On Tue, 2010-02-23 at 08:25 +0900, Tadashi G. Takaoka wrote: > Hi, Carl. > > That is the bug in mspgcc4. It was fixed by this > commit<http://mspgcc4.svn.sourceforge.net/viewvc/mspgcc4/ports/gcc-4.x/gcc/config/msp430/msp430-function.c?view=diff&r1=85&r2=86>. > Could you try to the latest mspgcc4 build? > > (Sorry for my previous mail. That was totally missed the point...) > > 2010/2/23 Carl <[email protected]>: > > Here is another program to illustrate the problem I'm seeing. The > > problem is evident independent of gdb. > > > > #include <io.h> > > int main() > > { > > unsigned long i; > > P4DIR |= 0x0e; /* set P4.1-3 to output direction */ > > P4OUT = 0; /* set the three LEDs to off */ > > i = 123; > > if (i == 123) > > P4OUT |= 0x04; /* turn on P4.2 */ > > for(; i<10000; i++) > > { > > if ((i%1000)==0) > > P4OUT ^= 0x02; /* toggle P4.1 */ > > } > > if (i == 10000) > > P4OUT |= 0x08; /* turn on P4.3 */ > > LPM0; > > } > > > > What I would expect to see is that P4.1 LED toggles 10 times, and P4.2 > > and P4.3 LEDs turn and stay on. I would expect to see this behavior if i > > is on the stack or in a register. I do see the expected behavior if I > > declare i as a global variable. I don't see the expected behavior with > > the above program. With the above program none of the LEDs turn on at > > all. > > > > Attached is the .lst file. I don't know assembler and I'm new to the > > msp430 so I appreciate the help. I don't even understand the first line: > > > > 31 0000 3140 0000 mov #(__stack+4), r1 > > > > What is at stack+4? Shouldn't the stack be growing 'down'? > > > > (gdb) p &i > > $1 = (long unsigned int *) 0x3104 > > (gdb) p i > > $2 = 1518354610 > > (gdb) x /x 0x3100 > > 0x3100 <_reset_vector__>: 0x31004031 > > (gdb) x /x 0x3104 > > 0x3104 <__low_level_init>: 0x5a8040b2 > > (gdb) > > > > The command I used to generate the lst file is as follows: > > > > msp430-gcc -c -g -O0 -W -Wa,-a,-ad -mmcu=msp430x2618 > > -I/opt/mspgcc4/msp430-gcc-4.4.2/include/ main.c > main.lst > > > > Thanks for the comments so far. > > > > Carl > > > > > > On Mon, 2010-02-22 at 12:53 +0100, JMGross wrote: > >> Chances are, that the optimizer has replaced the 'variable' by a > register. > >> There's no reason to reserve space on the stack, increase it there and > then clean up the stack if the return value needs to be in R15 for return > anyway. > >> Also, since the scope of the variable is limited to the function and the > address(!) of the variable is never forwarded anywhere, declaring it > volatile has no effect at all. > >> I _think_ there is a compiler flag to disable register variables. But > normally, the compiler uses them, in any optimisation stage. > >> > >> My guess is that GDB gets the symbol, but cannot handle it properly and > just assumes it somewhere at the start of .text. Or the linker has put it at > start of .txt since it isn't used anywhere. > >> A look into the .lst file should make things clear. > >> This is always my reference if something goes wrong. > >> My bet is that this address is never accessed anywhere and all is done > directly in a register. > >> > >> JMGross > >> > >> ----- Ursprüngliche Nachricht ----- > >> Von: Carl > >> An: GCC for MSP430 - http://mspgcc.sf.net > >> Gesendet am: 20 Feb 2010 22:16:22 > >> Betreff: Re: [Mspgcc-users] stack variable in flash? > >> > >> If I declare it as a global it is where I expect at the beginning of RAM > >> (0x1100). But if it is on the stack in the main function, even if I > >> declare it volatile, use asm(""); // __asm__ __volatile__ (""); or pass > >> it to a function, the variable address is in flash at 0x3102. It doesn't > >> make sense. > >> > >> Now if I use the program: > >> > >> #include <io.h> > >> > >> int f1() > >> { > >> volatile int i = 5; > >> i += 2; > >> return i; > >> } > >> > >> int main() > >> { > >> while(1) > >> { > >> f1(); > >> } > >> } > >> > >> The variable i address is on the stack in RAM at 0x30f8 which makes > >> sense. But if I change the compile option to use -02. Then the function > >> stack variable, i, goes back to being located in flash at 0x3102. And > >> it's value is not initialed to 5 nor is 2 added to it. The value of i is > >> constant = 12544 (0x3100.) > >> > >> > >> > ------------------------------------------------------------------------------ > >> Download Intel® Parallel Studio Eval > >> Try the new software tools for yourself. Speed compiling, find bugs > >> proactively, and fine-tune applications for parallel performance. > >> See why Intel Parallel Studio got high marks during beta. > >> http://p.sf.net/sfu/intel-sw-dev > >> _______________________________________________ > >> Mspgcc-users mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Mspgcc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
