Forums

Atmel Studio 6: local variable not shown at Locals Window

Started by Love Work July 25, 2012
I am testing the sample project ADS7843_EXAMPLE1 with SAM3S-EK2 and Atmel 
Studio 6. I am using SAM-ICE (SEGGER) for debug via JTAG.

I set a break point at main function and debug the project, and it did stop 
at the break point. The first line of code at main function is a definition 
of a local variable.
uint8_t uc_result = 0;

However, I didn't see this local variable being shown at "Locals" window. I 
tried to add this variable to "Watch 1" window, and got the following error:

Name                   Value                              Type
uc_result               Optimized away              Error

Is there any way to show the value of the variable, or stop the 
optimization?

Thank you in advance! 


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
I fixed the problem by myself. It is due to optimization. Set the 
Optimization level to None will fix the problem.



"Love Work" <lovemywork@live.ca> wrote in message 
news:jupk5k$1v07$1@adenine.netfront.net...
>I am testing the sample project ADS7843_EXAMPLE1 with SAM3S-EK2 and Atmel >Studio 6. I am using SAM-ICE (SEGGER) for debug via JTAG. > > I set a break point at main function and debug the project, and it did > stop at the break point. The first line of code at main function is a > definition of a local variable. > uint8_t uc_result = 0; > > However, I didn't see this local variable being shown at "Locals" window. > I tried to add this variable to "Watch 1" window, and got the following > error: > > Name Value Type > uc_result Optimized away Error > > Is there any way to show the value of the variable, or stop the > optimization? > > Thank you in advance! > > --- Posted via news://freenews.netfront.net/ - Complaints to > news@netfront.net ---
--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
On Wednesday, July 25, 2012 1:21:41 PM UTC-7, Love Work wrote:
> I fixed the problem by myself. It is due to optimization. Set the > Optimization level to None will fix the problem.
Or fix your code. The compiler is optimizing it away because it's unnecessary or unused. Why are you watching the unnecessary variable? Just do something with the variable.
On 07/25/2012 03:30 PM, me@linnix.info-for.us wrote:
> On Wednesday, July 25, 2012 1:21:41 PM UTC-7, Love Work wrote: >> I fixed the problem by myself. It is due to optimization. Set the >> Optimization level to None will fix the problem. > > Or fix your code. The compiler is optimizing it away because it's unnecessary or unused. Why are you watching the unnecessary variable? Just do something with the variable. >
Or it was optimized into a register so there is no local storage value to display. Even if it is still in a register when the display attempt is dine the debugger may not be aware of that fact. At times I have had to go through the generated code, figure out which reg the variable was optimized into, and then do a register display to find the value.
On Wed, 25 Jul 2012 13:30:37 -0700, me wrote:

> On Wednesday, July 25, 2012 1:21:41 PM UTC-7, Love Work wrote: >> I fixed the problem by myself. It is due to optimization. Set the >> Optimization level to None will fix the problem. > > Or fix your code. The compiler is optimizing it away because it's > unnecessary or unused.
The variable may be "unnecessary" insofar as the compiler can generate equivalent code which doesn't directly involve the variable, but that doesn't mean that there's anything wrong with the original code. E.g. given the code: for (int i = 0; a[i]; i++) a[i]++; the compiler could generate equivalent code: for (int* p = a; *p; p++) (*p)++; In which case, attempting to view the value of "i" will fail, as it has been optimised away.
On Jul 25, 10:15=A0pm, "Love Work" <lovemyw...@live.ca> wrote:
> I am testing the sample project ADS7843_EXAMPLE1 with SAM3S-EK2 and Atmel > Studio 6. I am using SAM-ICE (SEGGER) for debug via JTAG. > > I set a break point at main function and debug the project, and it did st=
op
> at the break point. The first line of code at main function is a definiti=
on
> of a local variable. > uint8_t uc_result =3D 0; > > However, I didn't see this local variable being shown at "Locals" window.=
I
> tried to add this variable to "Watch 1" window, and got the following err=
or:
> > Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Value =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Type
> uc_result =A0 =A0 =A0 =A0 =A0 =A0 =A0 Optimized away =A0 =A0 =A0 =A0 =A0 =
=A0 =A0Error
> > Is there any way to show the value of the variable, or stop the > optimization? >
Normally if you mark the variable as 'volatile' it will not be optimized away.
On 26/07/2012 01:09, Dennis wrote:
> On 07/25/2012 03:30 PM, me@linnix.info-for.us wrote: >> On Wednesday, July 25, 2012 1:21:41 PM UTC-7, Love Work wrote: >>> I fixed the problem by myself. It is due to optimization. Set the >>> Optimization level to None will fix the problem. >> >> Or fix your code. The compiler is optimizing it away because it's >> unnecessary or unused. Why are you watching the unnecessary >> variable? Just do something with the variable. >> > Or it was optimized into a register so there is no local storage value > to display. Even if it is still in a register when the display attempt > is dine the debugger may not be aware of that fact. At times I have had > to go through the generated code, figure out which reg the variable was > optimized into, and then do a register display to find the value.
Note that optimised variables don't necessarily "live" in a particular register - they may migrate between registers. Modern versions of gdb can track such movement and continue "watching" such data, AFAIK, but not simpler debuggers like AVR Studio. And for "manual" tracking like you mentioned, you have to be aware of these possibilities.
On 25/07/2012 22:21, Love Work wrote:
<Fixed top-posting>

> "Love Work" <lovemywork@live.ca> wrote in message > news:jupk5k$1v07$1@adenine.netfront.net... >> I am testing the sample project ADS7843_EXAMPLE1 with SAM3S-EK2 and >> Atmel Studio 6. I am using SAM-ICE (SEGGER) for debug via JTAG. >> >> I set a break point at main function and debug the project, and it did >> stop at the break point. The first line of code at main function is a >> definition of a local variable. >> uint8_t uc_result = 0; >> >> However, I didn't see this local variable being shown at "Locals" >> window. I tried to add this variable to "Watch 1" window, and got the >> following error: >> >> Name Value Type >> uc_result Optimized away Error >> >> Is there any way to show the value of the variable, or stop the >> optimization? >> >> Thank you in advance! >>
> I fixed the problem by myself. It is due to optimization. Set the > Optimization level to None will fix the problem. > No, you didn't fix the problem - you just hid it by making a bigger problem. Don't cripple your compiler by disabling optimisation, and don't do your debugging using different compiler settings from your "real" release code. The easiest way to watch a particular variable like this is, as another poster suggested, by marking it "volatile". It will affect code generation and optimisation, to make the data visible, but the changes will be minimal.
On Jul 26, 9:58=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 25/07/2012 22:21, Love Work wrote: > <snip> > > > The easiest way to watch a particular variable like this is, as another > poster suggested, by marking it "volatile". =A0It will affect code > generation and optimisation, to make the data visible, but the changes > will be minimal.
What I sometimes do is have a global volatile variable and assign to it the variable I wish to inspect. Normally only in early debug phase, when issue is reolved the assignment is removed. Sort of like a debug printf :)
On 07/26/2012 02:56 AM, David Brown wrote:
> On 26/07/2012 01:09, Dennis wrote: >> On 07/25/2012 03:30 PM, me@linnix.info-for.us wrote: >>> On Wednesday, July 25, 2012 1:21:41 PM UTC-7, Love Work wrote: >>>> I fixed the problem by myself. It is due to optimization. Set the >>>> Optimization level to None will fix the problem. >>> >>> Or fix your code. The compiler is optimizing it away because it's >>> unnecessary or unused. Why are you watching the unnecessary >>> variable? Just do something with the variable. >>> >> Or it was optimized into a register so there is no local storage value >> to display. Even if it is still in a register when the display attempt >> is dine the debugger may not be aware of that fact. At times I have had >> to go through the generated code, figure out which reg the variable was >> optimized into, and then do a register display to find the value. > > Note that optimised variables don't necessarily "live" in a particular > register - they may migrate between registers. Modern versions of gdb > can track such movement and continue "watching" such data, AFAIK, but > not simpler debuggers like AVR Studio. And for "manual" tracking like > you mentioned, you have to be aware of these possibilities. >
Well yes, you have to figure out that the variable is actually in a reg and which one when you want to view it. If you stop somewhere the variable is not being used it may not be in a register. As another poster pointed out the variable may not even exist after optimization. There may be problems that only show up at higher optimization levels and disappear at lower optimization levels. This is always fun (in the sense of root canal work without Novocaine) trying to figure out if it is your problem (usually) or a compiler problem.