Optimized away

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I'm using AVRONE and in rhe watch in version 6.1 many of my variables are optimized away.
It worked fine in 5.x and 6.0beta.

How can I get them back?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read this about:

Optimization

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find variables get optimized away when they don't mean anything. Often, when I'm stepping through the code where the variable actually means something, it's there. If it is not there, it usually means that the program I wrote is not the program I intended to write and I've got the logic goofed up somewhere.

One thing the compiler does that confused me till I realized what it was doing. I had a bit of code like:

  x = 14;
  ... a bunch of stuff
  while (x>0)
  {
      ... do your thing
  }

So as I was stepping through a bunch of stuff, X was optimized away and it wouldn't let me see that X was 14. I found this rather puzzling, till just before I stepped into the loop. Then it jumped up to the X=14 line, and back to the while and I could now see that X was 14.

I sat befuddled for a time till I realized the compiler was smarter than I. You see, a bunch of stuff never referred to X, and the while loop was very short. So the compiler had moved the assignment X=14 to just before the while loop so it could keep X in a register and reduce the while loop to just a couple instructions.

In case you're wondering, I am easily befuddled.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby,

The puzzle there is why x, 14, or even the while conditional test would ever exist. Unless x was volatile the compiler should be able to see that x is assigned 14 and it never changes therefore "x>0" is always true therefore there's no need for any kind of test. The code should have simply been interpreted as:

  ... a bunch of stuff
  while (1)
  {
      ... do your thing
  } 

No x, no conditional test. If I build this:

int main(void) {
	int x;
	x = 14;
	while (x > 0) {
		PORTB = 0x55;
	}
}

I get this:

00000070 
: int main(void) { int x; x = 14; while (x > 0) { PORTB = 0x55; 70: 85 e5 ldi r24, 0x55 ; 85 72: 88 bb out 0x18, r24 ; 24 74: fe cf rjmp .-4 ; 0x72

Three opcodes repeated over and over. No 'x', no test. Just as you'd expect from a decent optimising compiler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My question was not about the optiimalization of the code but the fact that the debugger is not showing the variables.
I opened AVRStusio 6.0 (release2) and started with the same file (elf) and the variables was displayed.

Can anybody (also Atmel people) tell if this is the way the debugger shall work?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you read about optimization?

Do you mean that you actually started with excactly the same ELF file? Not a recompile with the 6.0Sp2 toolchain? Did you load the elf file into studio, mapped the source files and used that for debug in a Object File Project?

--- Start GCC Optimization chat ---

The fact is, since GCC is a optimizing compiler, variables will disappear.

This is optimization:
If you have a variable that is never used, why should GCC allocate space for it?

If code paths are unreachable ( if (test) {..} where test can be found to always equal 0)

If a variable is constant, why not use the constant?

The list here goes on and on, as GCC is quite clever on how it optimizes. If you want too see it, debugging in a mixed C+ASM view will show you quite a bit of how things are changed.

Between SP2 and 6.1, the toolchain was updated to a newer GCC version. This is probably the reason why some variables are no longer visible...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

This is probably the reason why some variables are no longer visible...

Indeed. This new 4.7.2 is getting really good at producing "tight" code, I've been really impressed.

One can always check the .lss or, if you use the options "-fverbose-asm -save-temps" the .s files to see what the compiler is up to. The Asm will likely confirm that sections of code have been removed or that variables don't actually "exist" as such.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I know the optimalization and appreciate that. Otherwise, my 192A3U device will have run out of flash.
But, as shown on the attached picture, the variable GlobalTimeStamp, is located in ram at address 0x53dd.
It is shown in the disassembly code, but not shown in the watch.

The debugger knows the variable and the address.
Why is it not showed it in the watch as it did in previous versions.
For me, this is annoying.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As Morten asked. Is this the same ELF but now debugged with the later issue debugger. Or is it the same source but rebuilt by the newer compiler and then debugged with the newer debugger.

IOW is it a change in the debug info the compiler is generating or a change in the way the debugger is interpreting info in the ELF?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got an error while building to 6.0 R2 and I was asked to use the last compiled code so I assume it was the elf file built for 6.1.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Asle wrote:
My question was not about the optiimalization of the code but the fact that the debugger is not showing the variables.
I opened AVRStusio 6.0 (release2) and started with the same file (elf) and the variables was displayed.

Can anybody (also Atmel people) tell if this is the way the debugger shall work?


There is an issue with version 6 where global variables are reported as optimised away. They are not .... it is just that the debugger does not show them.

Eg I have a global object but the debugger will not display it. when I step into a method of the object... hey presto.... the object is visible in the debugger. A conversation with the atmel team pointed (boom boom) at this being related to the this pointer.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the object is visible in the debugger. A conversation with the atmel team pointed (boom boom) at this being related to the this pointer.

Yes, but that was C++ and class specific?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it is c++ but it is not class specific.

it happens with all of my global classes i think. Perhaps there is an exception.... but I haven't found it yet.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

In adition to getting all my varaiables optimized away, I also get problem with setting breakpoints.

After reinstalling 6.1 beta,everything works fine.
So...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Torby,

The puzzle there is why x, 14, or even the while conditional test would ever exist. Unless x was volatile the compiler should be able to see that x is assigned 14 and it never changes therefore "x>0" is always true therefore there's no need for any kind of test. The code should have simply been interpreted as:

There's an update for x included in "do your thing," obviously. The point was I was expecting to see X=14 before there was any reason for X to be 14 so the compiler moved the assignment to just before there was and saved the code to keep it in a memory location.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Asle wrote:
I got an error while building to 6.0 R2 and I was asked to use the last compiled code so I assume it was the elf file built for 6.1.

I've always wondered why it asked that. If I wanted to run the old code, I wouldn't have edited it into new, erroneous code

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby,
It is not the point.
The piont is that AVRStudio 6.1 optimized away the variables in the debugger.
Version 6.1 beta works fine.
Anyway, I am not producing tools but code, so I stuck to the tools that works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hehe Good point. I tend to stay with a tool I know till it's not able to do something I want or need, then start posting lots of silly threads about, "How do you..."

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(see EDIT: below)

Globals can't be optimized as something in another compilation unit may access them so this seems most odd indeed. Of course at the actual point of usage what is held in some member of a struct may be copied into just a machine register and then not easily visible to the debugger.

One "fix" might be to copy the thing to be watched to a volatile first then use/watch that.

I wonder if you ask the debugger to watch *&something whether that forces it to access the base address where the thing is actually stored in memory? (or is its command interpreter clever enough to spot what *& means).

EDIT: curious I just responded to a "phantom" post that obviously disappeared while I was composing the reply. Ho hum. It was about global structs that were apparently "optimized away".