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 > > -- たかおかはちからをためている takaoka is charging up
