lkml.org 
[lkml]   [2015]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S
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


\
 
 \ /
  Last update: 2015-07-18 06:21    [W:0.856 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site