Carl, If your stack ends up in flash then you might have a problem with the linker description file or somewhere in the initialisation routines.
Nico Coesel At 15:08 20-2-2010 -0800, [email protected] wrote: > I don't think the optimizer is not removing code or variables when -O0. When stepping through with gdb if you try to display a variable that is optimized out, it notifies you by displaying <optimized out>. This is not happening. > >I've tried declaring a global variable it works as expected. > >The problem I'm observing is when a variable is on the stack. > >The code I'm posting is for example only in trying to illustrate a problem in my code where the stack variables are being used but do not have the expected values. When stepping through with gdb, the stack variables are is flash. I have assert statements in my code that catch this even when not using gdb. > >I can post a bigger example if that will help. > >Carl > > >On Sat, 20 Feb 2010 23:49:57 +0100 > "N. Coesel" <[email protected]> wrote: >>Try this first: >> >>volatile int i; >> >>int main() >>{ >> while(1) >> { >> i++; >> } >>} >> >> >>IMHO you are chasing a dead horse because the optimizer is removing code >>that doesn't do anything. Inside main, the scope of the variable is limited >>to main so volatile probably doesn't mean anything. >> >> >>At 14:16 20-2-2010 -0700, Carl wrote: >>>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.) >>> >>>I noticed at new version of mspgcc4 is out as of Feb 18, 2010. I've >>>tried to install it on both a Fedora 9 and a Ubuntu machine but get the >>>same error: >>> >>>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. >>> >>> >>>Carl >>> >>> >>> >>>On Sat, 2010-02-20 at 09:08 +0100, N. Coesel wrote: >>>> Carl, >>>> >>>> Try to declare it outside the function (as a global). >>>> >>>> At 19:43 19-2-2010 -0800, you wrote: >>>> >I tried declaring as volatile and it is at the exact same address. >>>> > >>>> >Carl >>>> > >>>> >On Sat, 20 Feb 2010 01:35:03 +0000 >>>> > "Wayne Uroda" <[email protected]> wrote: >>>> >>try declaring i as volatile, or the compiler will probably get rid of it >>>> since it has no effect or side-effect. >>>> >>Sent via BlackBerry from Vodafone >>>> >> >>>> >>-----Original Message----- >>>> >>From: Carl <[email protected]> >>>> >>Date: Fri, 19 Feb 2010 18:29:03 >>>> >>To: <[email protected]> >>>> >>Subject: [Mspgcc-users] stack variable in flash? >>>> >> >>>> >>I'm sure that I'm missing some basic here but I'm not sure what. The >>>> >>first variable on the stack is in an unexpected location. I would expect >>>> >>it to be located somewhere on the stack in RAM (0x30ff-0x1100) but it is >>>> >>located in flash memory and it does not get set or incremented. >>>> >> >>>> >> >>>> >>#include <io.h> >>>> >> >>>> >>int main() >>>> >>{ >>>> >> int i=0; >>>> >> while(1) >>>> >> i++; >>>> >>} >>>> >> >>>> > >>> >>> >>> >>>--------------------------------------------------------------------------- >>--- >>>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 > >
