Messages in this thread | | | Date | Fri, 17 Jul 2015 22:56:23 -0500 | From | Josh Poimboeuf <> | Subject | Re: [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
| |