Stack Usage Calculator

21 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a good gcc AVR stack usage calculator out there?
I am trying to use the GCC switch -fstack-usage,
but when I compile, their is no ".su" file created as the gcc documentation said it would be.

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

You may want to read this recent thread:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=74865

(moving this to GCC forum where it belongs)

 

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

12oclocker wrote:
Is there a good gcc AVR stack usage calculator out there?
I couldn't find one so I ended up writing it for my particular purpose. Computing stack usage by static code analysis can be fairly easy for specific use cases but is much more difficult for the general case. There is some discussion of the issues involved in this thread.

Also, see:
http://docs.tinyos.net/index.php/Stack_Analysis
http://www.cs.utah.edu/~regehr/stacktool

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

I looked at all that stuff, but can't find anything that works for the at90s2313 or attiny2313 chips,

Anyone know how to get -fstack-usage to work?

I am familiar with techniques on watching a stack variable on the edge of the stack, and seeing it it's been modified to detect an overflow, but it's kind of a pain to implement every project.
It's really going to be a pain to have to write something that analyzes the assembly code myself.

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

-Brad

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

12oclocker wrote:
It's really going to be a pain to have to write something that analyzes the assembly code myself.
It's not that bad, really. Especially so if you don't have to address the special cases (recursion, indirect jump/call, stacked interrupts), your application doesn't use crt functions that utilize the __prologue_saves__/__prologue_restores__ mechanism, and don't have any assembly language code that modifies the stack pointer in an unusual manner. You will have to track register content (essentially a simple-minded emulator) and be able to recognize/handle the stack pointer manipulation idioms employed by the avr-gcc code generator (several different cases).

The one that I wrote is integrated into the ZBasic compiler and thus is not usable as a standalone application. It utilizes information from the generated object code file and from the .sym file together with some information provided by the ZBasic compiler's code generator and knowledge about the multi-tasking structure to analyze stack use for one or more tasks in the user's program. After the analysis is done, it generates warnings if the stack size specified by the user for each task is less than the calculated maximum plus a user-specified padding value. It also detects situations where the calculation is indeterminate (recursion, indirect call/jump with no target data available, stack pointer manipulation involving values not known at compile time, etc.) and reports that fact.

As I indicated before, for a certain set of special cases it's simple, straightforward analysis. The more difficult challenge is in making a general purpose tool that works for a wide range of applications and programming styles.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

12oclocker wrote:
Anyone know how to get -fstack-usage to work?
A few months ago I was looking for the same thing, unsuccessfully. Also ended up writing my own utility that gets stack usage and call tree from the .elf file. You are welcome to try it. It is called ezstack and there is a link to it in this thread that Don Kinzer mentioned. Do not expect too much from it, however.

Eugene

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

ezharkov wrote:
12oclocker wrote:
Anyone know how to get -fstack-usage to work?
A few months ago I was looking for the same thing, unsuccessfully. Also ended up writing my own utility that gets stack usage and call tree from the .elf file. You are welcome to try it. It is called ezstack and there is a link to it in this thread that Don Kinzer mentioned. Do not expect too much from it, however.

Eugene

Ah, the code looks very nice! do you have a compiled exe? does it support the at90s2313 and the attiny2313?

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

12oclocker wrote:
do you have a compiled exe? does it support the at90s2313 and the attiny2313?
Well, I did not. But if you insist, there is one now: http://home.comcast.net/~ezstack/ezstack.exe Regarding attiny2313. Out of curiosity I tried it yesterday. It did not work. Because attiny2313 has less than 256 bytes of RAM and avr-gcc initializes only SPL. I fixed that. So, one could say it does support at90s2313 and attiny2313. On the other hand, there may be many other things that it does not support. I do use the utility myself and plan to support it for myself. But if you use any avr-gcc features that I do not use, then you may be on your own.

Eugene

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

ezharkov wrote:
12oclocker wrote:
do you have a compiled exe? does it support the at90s2313 and the attiny2313?
Well, I did not. But if you insist, there is one now: http://home.comcast.net/~ezstack/ezstack.exe Regarding attiny2313. Out of curiosity I tried it yesterday. It did not work. Because attiny2313 has less than 256 bytes of RAM and avr-gcc initializes only SPL. I fixed that. So, one could say it does support at90s2313 and attiny2313. On the other hand, there may be many other things that it does not support. I do use the utility myself and plan to support it for myself. But if you use any avr-gcc features that I do not use, then you may be on your own.

Eugene

very nice job!,
I tested it with a new project I was doing on a attiny2313 elf file, I do have a question though, It does not seem to detect any ram usage in my interrupts, would this be because I am not using anything except 'volatile static global' variables in my interrupts? or does it not analyze interrupts for this chip? again, I'm very impressed, very nice work!

I also did test it with a at90s2313 elf file, and this was the output it generated...
ezstack version 2
Text size = 1944
Unreached block 0x2 - 0x14 (size=20)
Unreached block 0x32 - 0x32 (size=2)
Unreached block 0x11c - 0x122 (size=8)
Unreached block 0x170 - 0x288 (size=282)
ezstack.c:1961: error
sim.addr = 0x53e sim.opcode=962c

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

12oclocker wrote:
It does not seem to detect any ram usage in my interrupts [...]
In my implementation, the code analyzes the stack use of all ISRs. It then adds the maximum of the stack use of all of the ISRs to the maximum direct use by each task (including the stack space needed to save the context due to a task switch) to arrive at the potential maximum stack use for each task.

Obviously, this strategy involves several assumptions including that interrupts are not nested and that the interrupt whose ISR has the maximum stack use could occur at the point of maximum direct stack use of the task. Clearly, this represents a worst-case analysis that may or may not reflect the actual maximum use that would be seen when the application runs.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Pages