Messages in this thread |  | | Date | Sun, 19 Mar 2023 12:14:22 +0800 | From | Donglin Peng <> | Subject | Re: [PATCH v4 1/2] function_graph: Support recording and printing the return value of function |
| |
On 2023/3/19 0:40, Steven Rostedt wrote: > On Fri, 17 Mar 2023 10:49:49 +0800 > Donglin Peng <pengdonglin@sangfor.com.cn> 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
|  |