avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Re: Stack use - possible bug


From: Dale
Subject: [avr-gcc-list] Re: Stack use - possible bug
Date: Wed, 9 Jun 2010 16:17:13 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Hi David                                         >@2010.06.09_15:46:55_+0200

> On 09/06/2010 15:26, Dale wrote:
> >Hi Eric,>@2010.06.09_15:16:08_+0200
> >
> >>
> >>You need to use the "noinline" function attribute on the initialise() 
> >>function.
> >>
> >
> >Sure, that's one solution. Another is to simply remove static from
> >initialise(). Its easy if you know which functions are affected.
> >
> 
> No, that's not a solution - trying to lie to the compiler is never
> (well, /almost/ never) the best idea.  Once avr-gcc moves over to
> gcc 4.5 and people start using link-time optimisation, the compiler
> will figure out by itself that the function is only called once even
> without the "static".
> 

Removing static works with current tools as a workaround.

I agree that noinline is the correct way to go.

> >However, its not always obvious what the compiler is going to do. And
> >therefore where to do this type of thing. Its the kind of issue that can
> >catch you unawares.
> >
> >The optimising is effectively creating stack-space for variables but not
> >destroying it. The boundary for where the variables are no longer used,
> >should be known.
> >
> 
> The compiler /does/ know when variables are used or not.  But the
> usual way to allocate frame space is to allocate the maximum needed
> space on function entry, and free it on function exit.  There are
> odd occasions like this one in which this is not the behaviour you
> want, but usually that produces the best code.  Similarly, the usual
> behaviour is to automatically inline functions that are known to be
> used only once.
> 
> In a one-off case like this, Eric's recommendation of a "noinline"
> function attribute is clear and simple to use.  If you want a more
> general solution, the compiler lets you fiddle with all sorts of
> parameters that control this sort of thing.  In particular, there
> are the "large-stack-frame" and "large-stack-frame-growth"
> parameters than you can play with.  Something like "--param
> large-stack-frame=20" might be more appropriate for your use than
> the standard, which is to allow a stack frame growth of 256 bytes.
> 

My current stack usage peaks at ~400 bytes. However, and I wanted to
avoid it but since you raised the above, I have two situations, one
which includes external memory and where I relocate the stack into the
bottom of memory. That way its in 'fast' ram and variables grow up into
external ram. The other has stack growing down from the top of the 8k.
Compiler parameters don't necessarily help with this.

These, as far as I'm concerned, are side-issues. I don't agree that they
should be necessary in an average application.

I did title this a 'possible' bug. My opinion is that it is but as noted
elsewhere perhaps at least a FAQ or a warning to the unwary.

My main assertion is that this may result in a significant amount of
precious RAM being used once and subsequently rendered unusable. Thats
not a good thing.

> See <http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Optimize-Options.html>
> 
> mvh.,
> 
> David
> 
> >>See here:
> >><http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Attributes.html#Function-Attributes>
> >>
> >>Eric
> >>
> >>>-----Original Message-----
> >>>From:
> >>>address@hidden
> >>>[mailto:address@hidden
> >>>org] On Behalf Of Dale
> >>>Sent: Wednesday, June 09, 2010 6:43 AM
> >>>To: address@hidden
> >>>Subject: [avr-gcc-list] Stack use - possible bug
> >>>
> >>>Hi
> >>>
> >>>Stumbled onto this due to dire shortage of ram and monitoring stack
> >>>usage. To get an idea of whether it was enough, etc.
> >>>
> >>>I'll try and put together sample code which replicates it but the
> >>>scenario for now is:
> >>>
> >>>static void initialise(void)
> >>>{
> >>>   char    buf[50];        // some data
> >>>
> >>>   // call a bunch of functions
> >>>}
> >>>
> >>>int main(void)
> >>>{
> >>>   initialise();
> >>>   
> >>>   // bunch of stuff
> >>>}
> >>>
> >>>Now, initialise() is only ever called once and therefore is optimised
> >>>and included inline into main().
> >>>
> >>>What I find is that space used by buf[] is never released from the
> >>>stack. There may in fact be more since initialise() calls a
> >>>whole bunch
> >>>of other functions, some of which may or may not have variables on the
> >>>stack and/or be one-off functions and as a result 'rolled-into' code
> >>>that then forms main().
> >>>
> >>>Given my constrained setup, its critical that this stack
> >>>space is freed.
> >>>
> >>>Anyone come across this? Is it a known issue?
> >>>
> >>>--
> >>>
> >>>Cheers,
> >>>
> >>>Dale.
> >>>
> >>>_______________________________________________
> >>>AVR-GCC-list mailing list
> >>>address@hidden
> >>>http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> >>>
> >>
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]