Stack profiling

--- Quote Start ---

The Nios II Software Developer's handbook states:

stack checking has performance costs. if you choose to leave stack checking turned

off, you must code your program so as to ensure that it operates within the limits of

available heap and stack memory.

Is there a way to initialize a memory area (i.e. the heap and/or stack) to a known value so that level testing/profiling can be performed? I want to know how much of this memory my program uses in practice.

Thanks,

-Brad

--- Quote End ---

If you are using uCOS-II, you can initialize the stacks before you setup the tasks. For example, in one design, I initialize task 1's stack to 0x11111111, task 2's to 0x22222222, etc., before I start the OS.

If you are not using an OS, then you can use C code to just fill the locations before them, or you can use linker sections, and linker fill values, eg., put each stack in their own section and give them names, and then use those names in the C-code ... but that is compiler dependent ... I forget how gcc does it. Generally its much easier for others to understand your code if you do all this in C code during initialization.

Cheers,

Dave

An issue worth remembering is that the maximum stack use is likely to be in an error path somewhere - possibly inside printf() or the logging functions. So looking at what has been written to the stack area isn't necessarily that useful.

For code that has no recursive or indirect calls and doesn't use alloca() it is possible to do a static analysis since compiler generated code (and most hand assembler) will have a fixed stack size/offset for each function and call site. Parse the compiler asm listing (gcc -S -fverbose-asm ...) or a disassembly of a fully fixed up progam image.