On 4/1/21 9:27 AM, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 02:09:54PM -0500, madvenka@xxxxxxxxxxxxxxxxxxx wrote:
>
>> + * FTRACE trampolines.
>> + */
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>> + { (unsigned long) &ftrace_graph_call, 0 },
>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> + { (unsigned long) ftrace_graph_caller, 0 },
>> + { (unsigned long) return_to_handler, 0 },
>> +#endif
>> +#endif
>
> It's weird that we take the address of ftrace_graph_call but not the
> other functions - we should be consistent or explain why. It'd probably
> also look nicer to not nest the ifdefs, the dependencies in Kconfig will
> ensure we only get things when we should.
>
I have explained it in the comment in the FTRACE trampoline right above
ftrace_graph_call().
/*
* The only call in the FTRACE trampoline code is above. The above
* instruction is patched to call a tracer function. Its return
* address is below (ftrace_graph_call). In a stack trace taken from
* a tracer function, ftrace_graph_call() will show. The unwinder
* checks this for reliable stack trace. Please see the comments
* in stacktrace.c. If another call is added in the FTRACE
* trampoline code, the special_functions[] array in stacktrace.c
* must be updated.
*/
I also noticed that I have to fix something here. The label ftrace_graph_call
is defined like this:
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
nop // If enabled, this will be replaced
// "b ftrace_graph_caller"
#endif
So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can address
this as well as your comment by defining another label whose name is more meaningful
to our use:
+SYM_INNER_LABEL(ftrace_trampoline, SYM_L_GLOBAL) // checked by the unwinder
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
nop // If enabled, this will be replaced
// "b ftrace_graph_caller"
#endif
Is this acceptable?
Thanks.
Madhavan
