That certainly looks strange how it is adding to the stack. (First line is taking the __stack symbol, adding 4, and putting it in R1 (the stack pointer). __stack is defined by the linker so the full linked listing may shed some light.
Can you use msp430-objdump -D output.elf To dump the final, linked assembly and post it? -D may not be the only option you need, I am away from the computer right now, it should be ok though iirc. Does the problem occur if you use optimisations like -O2? Or if you don't use long variables? - Wayne Sent via BlackBerry from Vodafone -----Original Message----- From: Carl <[email protected]> Date: Mon, 22 Feb 2010 12:21:01 To: <[email protected]> Subject: Re: [Mspgcc-users] stack variable in flash? 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
