[cfe-dev] naked attribute

[reed kotler]

On 05/10/2013 06:33 AM, Rafael Espíndola wrote:
>> I think we should only produce the unreachable in places where the compiler
>> would implicitly insert a return.
>>
>> If the user actually has a "return" or "return xxx", we should honor that;
>> however it's not clear
>> what it would mean exactly.
> This part is really odd on the gcc side: It sets up the return value,
> but doesn't actually return. It is also documented that the only safe
> thing to put in naked functions are inline asm statements, so I don't
> worry too much about the other cases.
>
>> If we don't intend to honor the explicit return, then we should print a
>> warning and say what we are doing: i.e. turning it into unreachable, or
>> ignoring it, or whatever it is that we are doing, or maybe make it an error
>> to have an explicit return in a naked procedure.
>>
>> We discussed this earlier but I just wanted to bring it up again.
> I would definitely welcome a warning on the lines of "only inline asms
> are guaranteed to work on naked functions".
>
> Cheers,
> Rafael
I think that people do more than just simple inline assembly in gcc even 
though the manual says that.

Basically you have to not do things that require a stack setup.

I recently opened a discussion on this on the gcc developers list. Here 
is one post from someone that has experience using naked functions for 
ARM. You might find the thread there to be useful.

..........
On 03/05/13 16:03, Richard Sandiford wrote:
> David Brown <david at westcontrol.com> writes:
>> Personally, I've used "naked" when I want to write pure assembly code
>> and don't want extra stack frames or "return" codes.  I don't want to
>> write stand-alone assembly files (I've written mountains of them in the
>> past, and hope they stay in the past).  I am happier using the very nice
>> flexible gcc inline assembly syntax.
>
> The full inline asm syntax, such as:
>
>     asm ("..." : "=r" (result) : "i" (100))
>
> is specifically forbidden in naked functions, because in general GCC can
> only satisfy the constraints by building its own frame:
>
>    Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to 
> indicate that
>    the specified function does not need prologue/epilogue sequences 
> generated by
>    the compiler.  It is up to the programmer to provide these 
> sequences. The
>    only statements that can be safely included in naked functions are
>    @code{asm} statements _that do not have operands_.  All other 
> statements,
>    including declarations of local variables, @code{if} statements, 
> and so
>    forth, should be avoided.
>
> (my emphasis).  Naked functions must have a body of the form:
>
> {
>    asm ("....");
> }
>
> i.e. an asm with just a plain string, and no other statements or
> local variables.  So you don't really get any more flexibility
> by using inline asms over using assembly files.
>
> Thanks,
> Richard
>

In practice, it is perfectly possible to have full inline assembly with 
variables inside "naked" functions.  It is also possible to use normal C 
code - in fact this is regularly done on targets such as the AVR that 
support "naked".

The limitation with "naked" is that the compiler does not generate a 
stack frame.  So if your code requires a stack frame, you have to do it 
manually in assembly - though obviously you are almost certainly better 
off using a normal non-naked function in this case.  But for processors 
with plenty of registers, you seldom need a stack frame - stick to the 
"volatile" registers and you will be fine.

The documentation here could certainly be a lot clearer, since there is 
no doubt that you can use a lot more than just simple asm statements 
inside naked functions - and no doubt that it is very useful to be able 
to use simple, restricted C code and advanced inline assembly.  Examples 
can be seen at the end of this page:

<http://www.nongnu.org/avr-libc/user-manual/mem_sections.html#c_sections>

With a quick test using the AVR port (since I am familiar with it), 
version 4.5.1 (a little old, but I have it on this machine), I can see 
that code the requires a stack frame is generated as normal, but missing 
the prologue and epilogue that actually create and destroy the stack frame.

What would be very nice is for the compiler to generate a warning or 
error message if a stack frame is needed inside a "naked" function - the 
compiler already has this information (in order to implement 
-fomit-frame-pointer).  That would make "naked" safer, and therefore 
more usable.

But even without that, it is a feature that is useful on special 
occasions, for people who know what they are doing.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130510/2f650a97/attachment.html>