Debugger doesn't show any data.

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

I just installed the latest Studio.  It didn't fix a problem I had with an earlier version of 7.0.  It always says "identifier unknown".  Gdb or no gdb, it says the same thing.  I tried various optimization things, including "Optimize debugging experience". 

 

In the following pictures, signals is a class member.  my_signals is a local, on the stack as you can see.  I don't think I had this problem with Studio 6.2.

 

 

 

 

 

 

EDIT:  Most of my functions could be inlined.  Could that be the problem?

 

Last Edited: Wed. Nov 22, 2017 - 10:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve, I had problems like this with 'normal' c code under earlier versions of studio too, in my case the problem was that the variables were optimized out, and all the things that happened just happened inside the R0 - R31 registers.

 

You could have a look in the compiled code to see were the writing is actually done too. if it is a register the variable is optimized away, else it indeed is a studio bug. Note that with the new studio also comes a new compiler, package so might be that they turned up the optimization a bit further. I think it was the lss file you had to take a look in. and you can search for the string "combined_signals My_signals = signals" to save some scrolling time.

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

I've had this problem for 12 years starting with Studio 4.  I think it was fixed in Studio 6.2.  I'll give that a try.  When I ran this latest 7.0 it forced me to reluctantly update the firmware in my Atmel ICE.  I hope it will downgrade the firmware if Studio 6.2 requires it.

 

The .lss showed only registers in that function.

 

I looked again at the compiler optimization and saw a new entry called Debugging.  I changed it to the maximum.  Now the debugger shows the stack object but not the class member.  This may be enough for now.  I'll give it a try.  

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

Can you watch "this"? If you can does that lead to this->signals? Is that visible?

 

BTW I notice the implementation here is just:

void ProcessEvents() {

rather than the expected:

void className::ProcessEvents() {

So presumably you are using "using" ? Wonder if that is somehow confusing it?

steve17 wrote:
EDIT: Most of my functions could be inlined. Could that be the problem?
Oh I see so this is actually in the class declaration? (and hence no ClassName::). I would still expect it to have worked but what happens if you try the same thing split between .h and .cpp with ClassName:: ? (just put a declaration for ProcessEvents2() in the header then implement ClassName::ProcessEvents2() in a separate CPP using the same body as the above).

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

,cpp files are for losers.  wink

 

I've got hundreds of functions and almost all are in the class definition.

 

I could mention the this pointer in the class.  I think I can reference class member objects with this->membername. 

 

I'll figure out my weird problem one way or the other.  Now that I got the debugger to see stack objects, that may be enough.

 

I could do what I've done in the past and put values into general purpose registers.  The debugger can see them there.  

 

I've got AS 6.2 around and I have an old JTAGICE mkII that's probably set up for AS 6.2.

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

You might experiment with some of the debugging options more specific than just "-g"  https://gcc.gnu.org/onlinedocs/g...

I vaguely recall some instance on some CPU/debugger combo where "-gdwarf-2" or something similar helped improve the debugging experience.

 

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

I'll take a look at it.

 

Just seeing the stack objects allowed me to figure out the explanation of the weird behavior of my software.