Re: [PATCH v4 1/2] function_graph: Support recording and printing the return value of function
From: Donglin Peng <hidden>
Date: 2023-03-19 04:14:53
Also in:
linux-arm-kernel, linux-riscv, lkml
From: Donglin Peng <hidden>
Date: 2023-03-19 04:14:53
Also in:
linux-arm-kernel, linux-riscv, lkml
On 2023/3/19 0:40, Steven Rostedt wrote:
On Fri, 17 Mar 2023 10:49:49 +0800 Donglin Peng [off-list ref] wrote:quoted
quoted
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