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

[Ingo Molnar <mingo@kernel.org>]

* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> 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.

Still the same argument applies: it's a debug info detail we should hide as much 
as sensibly possible. In the CONFIG_FRAME_POINTERS=y case it will be code, in the 
future !CONFIG_FRAME_POINTERS case it will be nothing.

> > 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.

Well, we could use LEAF_FUNCTION to mark that fact.

Wether a function written in assembly is a leaf function or not is a higher level 
(and thus more valuable) piece of information whether we generate frame pointer 
debuginfo or not.

> 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?

'ENDPROC' is really leftover from older debuginfo cruft, it's not a valuable 
construct IMHO, even if it's (sadly) ubiquitious.

We want to create new, clean, as minimal as possible and as clearly named as 
possible debuginfo constructs from first principles.

Thanks,

	Ingo