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

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

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


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

Hi Colin                                         >@2010.06.09_15:36:23_+0200

> Hi Dale,
> 
> > However, its not always obvious what the compiler is going to do. And
> > therefore where to do this type of thing.
> 
> There are many issues like this that you need to inspect the resulting code
> to see what the compiler is doing. In this case it is saving a bit of code
> space, but at the expense of more SRAM.
> 
> It's fairly typical IMHO to need to rewrite things slightly or just trigger
> specific optimizations in the compiler based on how it interprets your code.
> The compiler is pretty smart, but they haven't yet got the mind-reading
> interface working ;-)
> 

I disagree that its difficult. If the function is called when its not
inline it creates space for local variables on entry and then frees it
up on exit. 

Why, when its inlined, does the compiler 'forget' that... I just think
its being dumb.

> Regards,
> 
>   -Colin
> 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of Dale
> Sent: June 9, 2010 2:26 PM
> To: Weddington, Eric
> Cc: address@hidden
> Subject: Re: [avr-gcc-list] Stack use - possible bug
> 
> 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.
> 
> 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.
> 
> > See here:
> >
> <http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Attributes.html#Functi
> on-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
> > > 
> > 
> 
> _______________________________________________
> 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]