[Top][All Lists]

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

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

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Potential stack corruption in naked functions at -O0
Date: Fri, 28 Sep 2012 22:07:27 +0200
User-agent: Thunderbird (Windows/20100228)

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
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
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

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...


reply via email to

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