RE: AW: [avr-gcc-list] stack layout

[Benjamin Titzer]

On Fri, 24 Jun 2005, stevech wrote:

> For estimating stack depth in a single-stack operating environment, I have
> used a bit of code in the real time clock interrupt service. It maintains a
> variable which depicts the deepest stack nesting seen since power up (or
> since some process reset the variable). If the application code function
> calls are rather random in time versus the clock interrupts, over time, this
> "low water mark" will be a good indicator, and more so if the I/O stimuli
> are all activated. The OPEX operating system (on AVRfreaks.net academy) has
> this built-in.
>

This can also be done in simulation without any modifications to the
source or binary program using monitors such as those available in Avrora.
There is one stack usage monitor available in the current release.

-B

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of
> John Altstadt
> Sent: Friday, June 24, 2005 6:31 AM
> To: address@hidden
> Subject: Re: AW: [avr-gcc-list] stack layout
>
> Russell Shaw wrote:
> > Haase Bjoern (PT-BEU/EMT) * wrote:
> >
> >> Joerg Wunsch wrote
> >>
> >>> No, you cannot perform overlap checks for the stack anyway, at not
> >>> least useful ones. [snip] and if
> >>> you as the programmer are changing that model, it's your
> >>> responsibility to ensure there's enough room for the stack.
>
> >> Actually it seems that there is a feature of gcc (yet unsupported by
> >> the AVR port) to switch on stack-checks at runtime each time new space
> >> on the stack is needed. Of course this would slow down execution, but
> >> I think that implementing this could be *very* helpful for debugging
> >> and testing purposes.
>
> >
> > At strategic points you could do:
> >
> >   size_t freespace = alloca(0) - sbrk(0) + 1;
>
> A common technique with bigger systems is to write a known value to the
> entire stack space at startup and then supply a user test function that
> will scan the allocated stack for that value. The upside is that there
> is no run-time impact. The downside is that you have to provide some
> sort of minimal user interface to run this test function on the bench
> and give the tester some meaningful results.
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>