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

[Donglin Peng]

On 2023/3/19 0:40, Steven Rostedt wrote:
> On Fri, 17 Mar 2023 10:49:49 +0800
> Donglin Peng <pengdonglin@xxxxxxxxxxxxxx> wrote:
>
> > > So, really it depends what size of return value we want to report.
> > > Also, please bear in mind that where a function returns a 32-bit
> > > value, that will be in r0, and r1 will be whatever happened to be
> > > in it at function exit - there's no defined value for r1.
> > >    
> >
> > Thank you. I will document this as a limitation of fgraph return value.
> > It can just cover most cases at present and I think the r0 is enough.
>
> One thing we could possibly do here is to use BTF or objtool to denote
> the return value of each function and use 2 bits of the ftrace
> rec->flags to state that it is:
>
> 0 - void
> 1 - 1 word size return
> 2 - 2 word size return

Yeah, the BTF contains details of the function return type. However the
direct search cost is a bit high, we may parse it to fill the 
dyn_ftrace.flags.

> I believe we can get access to the function's rec via the return call
> (or add that access) and pass both words to the return function, and
> then the return callback can use this lookup to determine what values
> are useful or not.

Yeah, we can obtain the function address via ret_stack in the function
ftrace_pop_return_trace, then pass the address to lookup_rec to
find the dyn_ftrace.

> In any case, I would suggest passing both regs to the callback, and for
> now just ignore the second reg until we can come up with a way to
> differentiate each function.

Yeah, I will modify it to pass two regs in v5.

> -- Steve