Messages in this thread | | | Date | Wed, 22 Mar 2023 17:01:54 +0800 | Subject | Re: [PATCH v5 1/2] function_graph: Support recording and printing the return value of function | From | Donglin Peng <> |
| |
On 2023/3/22 1:31, Russell King (Oracle) wrote: > On Mon, Mar 20, 2023 at 06:16:49AM -0700, Donglin Peng wrote: >> diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S >> index 3e7bcaca5e07..ba1986e27af8 100644 >> --- a/arch/arm/kernel/entry-ftrace.S >> +++ b/arch/arm/kernel/entry-ftrace.S >> @@ -258,7 +258,15 @@ ENDPROC(ftrace_graph_regs_caller) >> #ifdef CONFIG_FUNCTION_GRAPH_TRACER >> ENTRY(return_to_handler) >> stmdb sp!, {r0-r3} >> +#ifdef CONFIG_FUNCTION_GRAPH_RETVAL >> + /* >> + * Pass both the function return values in the register r0 and r1 >> + * to ftrace_return_to_handler >> + */ >> + add r2, sp, #16 @ sp at exit of instrumented routine >> +#else >> add r0, sp, #16 @ sp at exit of instrumented routine >> +#endif >> bl ftrace_return_to_handler > ... >> -unsigned long ftrace_return_to_handler(unsigned long frame_pointer) >> +static unsigned long __ftrace_return_to_handler(unsigned long retval_1st, >> + unsigned long retval_2nd, unsigned long frame_pointer) > ... >> +#ifdef CONFIG_FUNCTION_GRAPH_RETVAL >> +unsigned long ftrace_return_to_handler(unsigned long retval_1st, >> + unsigned long retval_2nd, unsigned long frame_pointer) >> +{ >> + return __ftrace_return_to_handler(retval_1st, retval_2nd, frame_pointer); >> +} >> +#else >> +unsigned long ftrace_return_to_handler(unsigned long frame_pointer) >> +{ >> + return __ftrace_return_to_handler(0, 0, frame_pointer); >> +} >> +#endif >> + > > Hi, > > To echo Mark's criticism, I also don't like this. I feel it would be > better if ftrace_return_to_handler() always took the same arguments > irrespective of the setting of CONFIG_FUNCTION_GRAPH_RETVAL. > > On 32-bit ARM, we have to stack r0-r3 anyway to prevent the call to > ftrace_return_to_handler() corrupting the return value, and these > are the registers we need. So we might as well pass a pointer to > these stacked registers. Whether that's acceptable on other > architectures, I couldn't say.
Agree, I think we can introduce a new structure called pt_ret_regs for each relevant architecture. The pt_ret_regs should only contain the return registers and the frame pointer register, for arm, they are r0~r3 and r11.Then we can pass the pointer to the pt_ret_regs to ftrace_return_to_handler.
> > Thanks. >
| |