Re: RFC: Doc update for attribute

["Carlos O'Donell" <carlos at redhat dot com>]

On 05/12/2014 11:13 PM, David Wohlferd wrote:
> After updating gcc's docs about inline asm, I'm trying to improve
> some of the related sections. One that I feel has problems with
> clarity is __attribute__ naked.
> 
> I have attached my proposed update. Comments/corrections are
> welcome.
> 
> In a related question:
> 
> To better understand how this attribute is used, I looked at the
> Linux kernel. While the existing docs say "only ... asm statements
> that do not have operands" can safely be used, Linux routinely uses
> asm WITH operands.

That's a bug. Period. You must not use naked with an asm that has
operands. Any kind of operand might inadvertently cause the compiler
to generate code and that would violate the requirements of the
attribute and potentially generate an ICE.

The correct solution, and we've talked about this in the past, is to
have the compiler generate a hard error if you use an asm statement
with operands and naked. I don't know what anyone ever got around to it.

> Some examples:
> 
> memory clobber operand:
> http://lxr.free-electrons.com/source/arch/arm/kernel/kprobes.c#L377 

Is this needed?

> Input arguments:
> http://lxr.free-electrons.com/source/arch/arm/mm/copypage-feroceon.c#L17

This is a bug and it's wrong. The naked asm can just assume the use of
first and second arguments as per AAPCS.

> Since I don't know why "asm with operands" was excluded from the
> existing docs, I'm not sure whether what Linux does here is supported
> or not (maybe with some limitations?). If someone can clarify, I'll
> add it to this text.

The "asm with operands" was excluded because to allow them in the
implementation would require gcc to potentially copy the argumnents
to temporary storage depending on their type. There is no prologue so
the compiler has no stack in which to place the arguments, therefore
the result is an impossible to satisfy constraint which usually results
in an ICE or compiler error.

Even if you said it was OK to use the incoming arguments with "r" type
operands the optimization level of the compile might inadvertently
try to force those values to the stack and that again is an impossible
to satisfy condition with a naked function.

> Even without discussing "asm with operands," I believe this text is 
> an improvement.
> Thanks in advance,
> dw
> 
> extend.texi.patch
> 
> 
> Index: extend.texi
> ===================================================================
> --- extend.texi	(revision 210349)
> +++ extend.texi	(working copy)
> @@ -3330,16 +3330,15 @@
>  
>  @item naked
>  @cindex function without a prologue/epilogue code
> -Use this attribute on the ARM, AVR, MCORE, MSP430, NDS32, RL78, 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.  Naked functions should be used to implement the
> -body of an assembly function, while allowing the compiler to construct
> -the requisite function declaration for the assembler.
> +This attribute is available on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX 
> +and SPU ports.  It allows the compiler to construct the requisite function 
> +declaration, while allowing the body of the function to be assembly code. 
> +The specified function will not have prologue/epilogue sequences generated 
> +by the compiler; it is up to the programmer to provide these sequences if 
> +the function requires them. The expectation is that only Basic @code{asm} 
> +statements will be included in naked functions (@pxref{Basic Asm}). While it 
> +is discouraged, it is possible to write your own prologue/epilogue code 
> +using asm and use ``C'' code in the middle.

I wouldn't remove the last sentence since IMO it's not the intent of the feature
to ever support that and the compiler doesn't guarantee it and may result
in wrong code given that `naked' is a fragile low-level feature.

>  
>  @item near
>  @cindex functions that do not handle memory bank switching on 68HC11/68HC12

Cheers,
Carlos.