lkml.org 
[lkml]   [2023]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2023-03-27 01:06    [W:0.047 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site