On Mon, Jul 20, 2015 at 07:21:24PM +0200, Ingo Molnar wrote: > * Josh Poimboeuf <jpoim...@redhat.com> wrote: > > On Mon, Jul 20, 2015 at 09:56:11AM +0200, Ingo Molnar wrote: > > 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. > > Ok, I see how the naming scheme I proposed won't work with all that very > well, but > I'd still suggest using consistently named patterns. > > Let me suggest yet another approach. How about open-coding something like > this: > > FUNCTION_START(func) > > push_bp > mov_sp_bp > > ... > > pop_bp > ret > > FUNCTION_END(func) > > This is just two easy things: > > - a redefine of the FUNCTION_ENTRY and ENDPROC names > > - the introduction of three quasi-mnemonics: push_bp, mov_sp_bp, pop_bp - > which > all look very similar to a real frame setup sequence, except that we can > easily > make them go away in the !CONFIG_FRAME_POINTERS case. > > The advantage of this approach would be: > > - it looks pretty 'natural' and very close to how the real disassembly looks > like in CONFIG_FRAME_POINTERS=y kernels. So while it's not as compact as > some > of the other variants, it's close to what the real instruction sequence > looks > like and that is a positive quality in itself. > > - it also makes it apparent 'on sight' that it's probably a bug to have > unbalanced push/pop sequences in a regular function, to any reasonably > alert > assembly coder. > > - if we ever unsupport framepointer kernels in the (far far) future, we can > get > rid of all lines with those 3 mnemonics and be done with it. > > - it's finegrained enough so that we can express all the special > function/tail > variants you listed above. > > What do you think?
I agree that the edge cases make FUNCTION_ENTRY and FUNCTION_RETURN less attractive. Slowly we are circling around to where we started :-) Personally, I prefer FRAME/ENDFRAME instead of push_bp/mov_sp_bp/pop_bp, because it more communicates *what* it's doing rather than how. IMO, it's easier to grok with a quick glance. > I'd still keep existing frame setup functionality and names and only use > these in > fixes, new code and new annotations - and do a full rename and cleanup once > the > dust has settled. That sounds good. -- 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/
