This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: naked function attribute support for Mips


On 03/05/13 16:03, Richard Sandiford wrote:
David Brown <david@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]