From: David Brown on 12 May 2010 02:53 On 11/05/2010 22:02, Grant Edwards wrote: > On 2010-05-11, John Speth<johnspeth(a)yahoo.com> wrote: >>>>>> 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. >>>> >>>> You're right but it needs to be a run time operation. >>> >>> 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. >> >> 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. > > Then that's the "former", not the "latter". > >> 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); > > As I posted earlier, try this: > > extern char __alt_stack_base, __alt_stack_limit; > > printf("%p %p\n",&__alt_stack_base,&__alt_stack_limit; > 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.
From: Grant Edwards on 12 May 2010 09:42 On 2010-05-12, David Brown <david(a)westcontrol.removethisbit.com> wrote: > On 11/05/2010 22:02, Grant Edwards wrote: >>> 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); >> >> As I posted earlier, try this: >> >> extern char __alt_stack_base, __alt_stack_limit; >> >> printf("%p %p\n",&__alt_stack_base,&__alt_stack_limit; >> > > 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. The thing to note is that they're not variables. They're symbols. -- Grant Edwards grant.b.edwards Yow! Hey, waiter! I want at a NEW SHIRT and a PONY TAIL gmail.com with lemon sauce!
From: John Speth on 12 May 2010 11:54 "John Speth" wrote > 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? 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. Thanks for the suggestions so far. John Speth --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Paul Keinanen on 12 May 2010 14:02 On Wed, 12 May 2010 08:54:56 -0700, "John Speth" <johnspeth(a)yahoo.com> wrote: >"John Speth" wrote >> 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? > >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. This has been the standard practice for decades in most non-virtual memory systems in which the hardware stack grows downwards. >I need to know >the bottom and top pointers to the heap/stack segment. 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. >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. 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).
From: John Speth on 12 May 2010 15:19 Thanks Paul. You're suggestions are what I ended up following independently to arrive at my final solution which I posted on the Altera NIOS forum at: http://www.alteraforum.com/forum/showthread.php?t=23009 Go to the end because I attached the wrong file. StackCheck.zip is the right one. JJS --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Seeking TAS151 Manual desperately Next: How to find memory data width (x16 or x32?) |