Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Sat, Jul 18, 2015 at 04:51:16AM +0200, Ingo Molnar wrote:
> Note what the names _don't_ contain: that we generate debug info! That fact is not 
> present in the naming, and that's very much intentional, because the precise form 
> of debug info is conditional:
> 
>   - if CONFIG_FRAME_POINTERS=y then we push/pop a stack frame
> 
>   - if (later on) we do CFI annotations we don't push/pop a stack frame but emit 
>     CFI debuginfo

According to current plan, the macro won't add CFI annotations.  That
will be done instead by a separate tool.  So the macro really is frame
pointer specific.

> 
> In that sense 'FRAME' should never be in these names I think, nor 'PROC' (which is 
> not symmetric).
> 
> Plus all 3 variants I suggested are very easy to remember, why I'd always have to 
> look up any non-symmetric macro name called 'PROC'...

The reason I suggested to put FRAME in the macro name is to try to
prevent it from being accidentally used for leaf functions, where it
isn't needed.

Also the naming of FUNCTION_ENTRY and FUNCTION_RETURN doesn't do
anything to distinguish them from the already ubiquitous ENTRY and
ENDPROC.  So as a kernel developer it seems confusing to me, e.g. how do
I remember when to use FUNCTION_ENTRY vs ENTRY?

-- 
Josh