Re: [PATCH v5 1/2] function_graph: Support recording and printing the return value of function

[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.