On Mon, Jul 20, 2015 at 09:56:11AM +0200, Ingo Molnar wrote: > > > > 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. Ok. So if I understand right, the proposal is: Replace *all* x86 usage of ENTRY/ENDPROC with either: FUNCTION_ENTRY(func) FUNCTION_RETURN(func) or LEAF_FUNCTION_ENTRY(func) LEAF_FUNCTION_RETURN(func) Those sound fine to me. I should point out that there are still a few cases where the more granular FRAME/ENDFRAME and ENTRY/ENDPROC macros would still be needed. For example, if the function ends with a jump instead of a ret. If the jump is a sibling call, the code would look like: FUNCTION_ENTRY(func) ... ENDFRAME jmp another_func ENDPROC(func) Or if it's a jump within the function to an internal ret: FUNCTION_ENTRY(func) ... 1: ... ENDFRAME ret 2: ... jmp 1b ENDPROC(func) Or if it jumps to some shared code before returning: FUNCTION_ENTRY(func_1) ... jmp common_return ENDPROC(func_1) FUNCTION_ENTRY(func_2) ... jmp common_return ENDPROC(func_2) common_return: ... ENDFRAME ret So in some cases we'd still need the more granular macros, unless we decided to make special macros for these cases as well. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
