[PATCH v4 1/2] function_graph: Support recording and printing the return value of function
Donglin Peng
pengdonglin at sangfor.com.cn
Sat Mar 18 21:14:22 PDT 2023
On 2023/3/19 0:40, Steven Rostedt wrote:
> On Fri, 17 Mar 2023 10:49:49 +0800
> Donglin Peng <pengdonglin at 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
More information about the linux-riscv
mailing list