From: David Brown on
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
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
"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
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
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 ---