Re: [avr-gcc-list] Potential stack corruption in naked functions at -O0

[Georg-Johann Lay]

Don't forget to use "Reply All" so that others are not excluded from the 
discussion.

Peter Vranken schrieb:
> Dear Johann,
>  
> To your information and referring to
> http://lists.gnu.org/archive/html/avr-gcc-list/2012-08/msg00015.html, as
> you wondered why someone could ever wish to have naked functions with a
> parameter:
>  
> I'm currently developing an RTOS implementation on AVR and struggled with 
> this issue also. In my concept, an active thread will suspend itself by
> invoking a method like:
>  
> eventVec_t suspend(eventVec_t eventMask, systemTime_t timeout);
>  
> eventMask is a bit vector of events to wait for, timeout a limitation of
> the time to wait for those events. After re-activation of the suspending
> task, the function will continue in the context of the suspended task and
> return the vector of events which were actually posted (including timeout
> event).
>  
> Obviously, the method is going to initiate a task switch. Therefore it
> needs to begin with saving the CPU context. I placed some in-line assembly
> code at the beginning of the function to do so and declared the function
> to be a naked one. In optimization levels other than -O0 this works fine,
> but with -O0 the stack is already corrupted before I got the chance to do
> anything.

Typically, OSes are distributed as objects (libraries) that link against 
the user application.  The OS maintainer/distributor will use the right 
options to build the OS binaries and likely he will use at least -O.

> So far I can live with the restriction not to use -O0 but I feel not
> comfortable with it as I don't know under whatever obscure circumstances
> (there are dozens of optimization related compiler flags) the compiler
> will again create such code. I need to double-check the compiler's
> assembly output after any code or configuration change.

A robust approach is to extend the compiler if an OS has special 
requirements.  One way would be to implement function attributes to help 
the OS to accomplish its tasks.

The functionality of naked, OS_task and OS_main is rather limited and I 
thought if a function attribute might be useful that allows to 
instrument functions by means of user code.

However, there was never such a feature request, and besides that, there 
are so many issues in the compiler that it's very unlikely I will ever 
find the time to implement such an extension.

For the time being, you can use a compiler version that comes with 
PR54220 fixed.  This is avr-gcc 4.6.4 (not yet released) or newer and 
4.7.2 (released 2012-09-20) or newer.

> Writing everything in pure assembler is the only way out I see at the
> moment but this rises the complexity significantly and would found on
> other internal compiler decisions like register usage etc. which are not
> guaranteed to my understanding.
>  
> Is there a chance to interact by in-line assembly code before and after the
> code generated for the function body? One could e.g implement his own stack
> frame before getting into the compiler generated code.

Instrumentation is too weak, IMO, because the function needs always to 
be inlined, i.e. it cannot be a solution in the avr backend alone.

> I would appreciate if there was at least a warning raised by the code
> generator that probably inconsistent code is generated.

ACK, but again:  So many issues, so little time...

Johann