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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
