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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
