<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/10/2013 06:33 AM, Rafael
Espíndola wrote:<br>
</div>
<blockquote
cite="mid:CAG3jRe+saMOZLvjJ0wh3tVDnDHaQBpa3jLScsONj73qWZmQXSw@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
I would definitely welcome a warning on the lines of "only inline asms
are guaranteed to work on naked functions".
Cheers,
Rafael
</pre>
</blockquote>
I think that people do more than just simple inline assembly in gcc
even though the manual says that.<br>
<br>
Basically you have to not do things that require a stack setup.<br>
<br>
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.<br>
<br>
..........<br>
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">On 03/05/13 16:03, Richard
Sandiford wrote:
<br>
<blockquote type="cite" style="color: #000000;">David Brown <a
class="moz-txt-link-rfc2396E"
href="mailto:david@westcontrol.com"><david@westcontrol.com></a>
writes:
<br>
<blockquote type="cite" style="color: #000000;">Personally, I've
used "naked" when I want to write pure assembly code
<br>
and don't want extra stack frames or "return" codes. I don't
want to
<br>
write stand-alone assembly files (I've written mountains of
them in the
<br>
past, and hope they stay in the past). I am happier using the
very nice
<br>
flexible gcc inline assembly syntax.
<br>
</blockquote>
<br>
The full inline asm syntax, such as:
<br>
<br>
asm ("..." : "=r" (result) : "i" (100))
<br>
<br>
is specifically forbidden in naked functions, because in general
GCC can
<br>
only satisfy the constraints by building its own frame:
<br>
<br>
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports
to indicate that
<br>
the specified function does not need prologue/epilogue
sequences generated by
<br>
the compiler. It is up to the programmer to provide these
sequences. The
<br>
only statements that can be safely included in naked
functions are
<br>
@code{asm} statements <span class="moz-txt-underscore"><span
class="moz-txt-tag">_</span>that do not have operands<span
class="moz-txt-tag">_</span></span>. All other statements,
<br>
including declarations of local variables, @code{if}
statements, and so
<br>
forth, should be avoided.
<br>
<br>
(my emphasis). Naked functions must have a body of the form:
<br>
<br>
{
<br>
asm ("....");
<br>
}
<br>
<br>
i.e. an asm with just a plain string, and no other statements or
<br>
local variables. So you don't really get any more flexibility
<br>
by using inline asms over using assembly files.
<br>
<br>
Thanks,
<br>
Richard
<br>
<br>
</blockquote>
<br>
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".
<br>
<br>
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.
<br>
<br>
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:
<br>
<br>
<a class="moz-txt-link-rfc2396E"
href="http://www.nongnu.org/avr-libc/user-manual/mem_sections.html#c_sections"><http://www.nongnu.org/avr-libc/user-manual/mem_sections.html#c_sections></a>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
But even without that, it is a feature that is useful on special
occasions, for people who know what they are doing.
<br>
<br>
<br>
</div>
<br>
</body>
</html>