Difference between revisions of "Stack Analysis"

From TinyOS Wiki
Jump to: navigation, search
(What is Stack Depth Analysis?)
Line 15: Line 15:
 
''Stack depth analysis'' offers a more principled alternative: static analysis of the compiled application in order to predict its worst case stack memory usage.
 
''Stack depth analysis'' offers a more principled alternative: static analysis of the compiled application in order to predict its worst case stack memory usage.
  
= Who Needs to Care About Stack Overflow? =
+
For applications that use a heap and/or threads, the situation is more complicated.
 +
 
 +
= Stack Depth Analysis for TinyOS =
 +
 
 +
A stack depth checking tool is available from the TinyOS CVS repository (and will be available in the next release following TinyOS 2.1).  You can get this tool either by checking out the entire repository or by using this [http://tinyos.cvs.sourceforge.net/viewvc/*checkout*/tinyos/tinyos-2.x/tools/tinyos/safe/tos-ramsize direct link] into the CVS repository.  You can run tos-ramsize directly, or have the TinyOS build system run it for you.
 +
 
 +
== Running tos-ramsize directly ==
 +
 
 +
Given an application for one of the AVR platforms, you can run a command like this:
 +
 
 +
<pre>
 +
[regehr@babel BaseStation]$ tos-ramsize micaz ./build/micaz/main.exe
 +
</pre>
 +
 
 +
The result should look something like this:
 +
 
 +
<pre>
 +
BSS segment size is 1708, data segment size is 16
 +
The upper bound on stack size is 538
 +
The upper bound on RAM usage is 2262
 +
There are 1834 unused bytes of RAM
 +
</pre>
 +
 
 +
= Getting More Information =
 +
 
 +
= Failure Modes =
 +
 
 +
= Limitations =
 +
 
 +
write me
 +
 
 +
= Internals =
 +
 
 +
write me

Revision as of 13:00, 13 April 2009

Memmap.png

What is Stack Depth Analysis?

Calling a function or handling an interrupt requires allocation of memory from the stack memory region. If the stack memory region is not large enough to hold the stack, RAM is corrupted, leading to difficult, non-deterministic node failure. For obvious reasons these failures cannot be replicated in TOSSIM.

In a TinyOS application (as in any embedded system lacking virtual memory) the size of the stack is determined statically and it is important that the size be chosen appropriately. The stack region must not be too small. If it is too large the system will operate correctly, but RAM that could have been put to good use is wasted.

TinyOS (without TOSThreads) has a single stack. When a heap is not in use, the size of the stack memory region is simply:

(RAM size) - (data segment size) - (BSS segment size)

The only question is: Is this region large enough? The most common way to answer this question is by running the system. If it crashes in a non-deterministic way, one of the things a developer will try is to reduce the size of the data or BSS segments.

Stack depth analysis offers a more principled alternative: static analysis of the compiled application in order to predict its worst case stack memory usage.

For applications that use a heap and/or threads, the situation is more complicated.

Stack Depth Analysis for TinyOS

A stack depth checking tool is available from the TinyOS CVS repository (and will be available in the next release following TinyOS 2.1). You can get this tool either by checking out the entire repository or by using this direct link into the CVS repository. You can run tos-ramsize directly, or have the TinyOS build system run it for you.

Running tos-ramsize directly

Given an application for one of the AVR platforms, you can run a command like this:

[regehr@babel BaseStation]$ tos-ramsize micaz ./build/micaz/main.exe 

The result should look something like this:

BSS segment size is 1708, data segment size is 16
The upper bound on stack size is 538
The upper bound on RAM usage is 2262
There are 1834 unused bytes of RAM

Getting More Information

Failure Modes

Limitations

write me

Internals

write me