I'm building a NIOS2 project which uses GCC tools and I'd like to write a C function that needs to know the stack top and stack bottom pointers at runtime.
What is the GCC method for getting the stack top and bottom pointers at runtime?
The first place that I'd look would be the linker command file (something_or_other.ld) -- if you're lucky they'll be called something like __stack_top and __stack_bottom. Failing that, look in the map file from your link for things called "stack". Failing that, grep.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
It's probably going to depend on what the crt0.s file you are linking against does. (You could disassemble that with objdump to see what symbols get used then write the appropriate code.)
Do you mean you need to know the limits at run time, or that you need to know how much of the stack is used at run time?
If it's the former, see Grant's response.
If it's the latter, then fill the stack with all zeros, or 0xDEADBEEF, or something, and test for how much is overwritten when you need to know how much of the stack's been used.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
It's the latter. My problem is NOT the mechanics of filling the stack and reading it to uncover used stack. My problem is how to identify the stack start and end in my C code. There's a simple solution that eludes me. I'm hoping somebody just knows. Google doesn't seem to give it up.
The map file has two likely variables that I read (__alt_stack_base and __alt_stack_limit) but they both evaluate to 0. The code compiles and links without errors:
extern int __alt_stack_base; extern int __alt_stack_limit; printf("%08X %08X\n",__alt_stack_base,__alt_stack_limit);
What is your goal? Do you want to know how much stack has been set aside by the linkage editor for your application? Or, do you want to know how much of that you are actually
*using* (in various contexts)?
Presumably, your OS doesn't dynamically grow the stack to fit your needs?
Just to clarify Grant's post (in case this thread ends up going round in circles...), the key point here is to look at the /addresses/ of these external linker-defined variables, not their values.
After some digging, I got a better understanding of NIOS memory layout.
NIOS memory is divided into two parts: RAM and ROM all implemented in FPGA block RAM. RAM and ROM is conceptual since it all lives in physical FPGA block RAM. The designer specifies how much block RAM shall be used for NIOS memory. Just enough block RAM is allocated for ROM and the rest is allocated for RAM. The RAM section gets a fixed amount for global variables with the remaining RAM given to heap and stack.
The heap and stack share the same segment. Stack growing down from the top. Heap growing up from the bottom. You hope they never meet. I need to know the bottom and top pointers to the heap/stack segment. The reason is so I can guage stack usage during field stress testing. I've done this before in several other embedded systems with success. Always, the difficult part is finding out how to get runtime access to the top/bottom pointers. crt0.s gives no direct clues. The linker script has a few holes too.
This has been the standard practice for decades in most non-virtual memory systems in which the hardware stack grows downwards.
What you really want to know is the top of the heap, which is typically an internal variable of the dynamic memory (malloc/free). If you have the source for these routines, it would be easy to make that symbol global.
The stack top (usually actually bottom) is of course always available from the stack pointer register.
If RSX-11 RTL style coroutines are used for register save at subroutine entry/exit, it is trivial to add a stack/heap overlap check at each subroutine entry.
I doubt that you would find anything usable in crt0.s, but you really need to look for the implementation of dynamic memory (malloc/free).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.