Call Stack Window is currently only supported for 32-bit devices.

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

Atmel Studion User Guide"4.16. Call Stack Window wrote:
Note:  Call Stack Window is currently only supported for 32-bit devices.
Arrrrg.

At least now I know why I couldn't find the window.

 

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

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

A Call Stack tab in VisualGDB AVR :

Step 13 in the VisualGDB AVR tutorial

via

VisualGDB Tutorials

Developing firmware for AVR devices with Visual Studio

https://visualgdb.com/tutorials/avr/

(step 13)

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:
A Call Stack tab in VisualGDB AVR :
That picture has "Hardware" not "Call Stack" selected??

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

Yes

The procedure does not call for one to select the Call Stack tab.

 

"Dare to be naïve." - Buckminster Fuller

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

Perhaps because that "Call Stack" tab isn't populated there either? I could be wrong but I thought Call Stack display required additional info generated in the load module. AFAIK avr-gcc does not generate this.

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

And, I don't think that the internal hardware debug module supports that, either. It would be nice to, at least, have a Call Stack display in the simulator but that would break the continuity between simulation and hardware debugging.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

I see a call stack tab, but not an actual call stack.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

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

Is this the sort of stack trace view that shows the "call" path to the current PC?   I didn't think that that was dependent on any hardware debugging features, but might be dependent on having a "standard stack frame" (push framepointer, move framepointer, sp, save and create space based on sp...  The point being that there's essentially a linked list of framepointers that you can parse)   Unfortunately, standard stack frames like this are relatively expensive to set up (especially on AVR), and modern compilers seem to go to significant effort to avoid creating them unless a function actually needs local variables and saved registers and stuff (more than can fit into registers.)  That makes compiled code much harder to backtrace (at a guess, it still ought to be POSSIBLE, if the compiler puts additional debug into into the meta-data for each function.  But...)

 

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

Note that in this documentation:

 

https://gcc.gnu.org/onlinedocs/g...

 

It says (for -O aka -O0):

-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging. 

and then for -O1, -O2 etc they all say "inherits all the settings from -O0".

 

Elsewhere it says:

 

 

So it might be possible to try -fno-omit-frame-pointer to get code that contains frame pointer info for use by a debugger. But I have a feeling this just doesn't have an effect for AVR.

Last Edited: Thu. Dec 14, 2017 - 10:34 AM