On 2023/3/16 20:39, Masami Hiramatsu (Google) wrote:

On Thu, 16 Mar 2023 11:18:23 +0800
Donglin Peng [off-list ref] wrote:

quoted

On 2023/3/15 22:57, Peter Zijlstra wrote:

quoted

On Wed, Mar 15, 2023 at 10:13:48AM -0400, Steven Rostedt wrote:

quoted

On Wed, 15 Mar 2023 14:49:11 +0100
Peter Zijlstra [off-list ref] wrote:

quoted

quoted

diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 1265ad519249..35ac9c58dc77 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S

@@ -348,6 +348,10 @@ SYM_CODE_START(return_to_handler)
   	movq %rax, (%rsp)
   	movq %rdx, 8(%rsp)
   	movq %rbp, %rdi
+#ifdef CONFIG_FUNCTION_GRAPH_RETVAL
+	/* Pass the function return value to ftrace_return_to_handler */
+	movq %rax, %rsi
+#endif
   
   	call ftrace_return_to_handler

What about the case of double register return values (when the value
is returned in the A,D pair) ?

Is there anything that does that in 64 bit kernels?

Note sure; but I have a patch series that introduces cmpxchg128 and
friends. Most of the actual functions are __always_inline, but still,
the moment a compiler decides to break out a subfunction on a u128
boundary we're in luck.

I have reviewed the kretprobe implementation and noticed that $retval
only retrieves the value of pt_regs.ax, which is an unsigned long data
type. I wrote a demo and tested it on an x86 machine, and found that
$retval only shows the least significant 32 bits of retval.Therefore,I
think it can be consistent with kretprobe.

Yeah, because it doesn't support 128bit type (u128/long long).
It is possible to support it, but I think we can just document this
as a limitation for fgraph return value. It is just for quickly trace
most of the return values.

Yeah,I will add this limitation to the documents in v5.

Thank you,

quoted

static noinline unsigned long long test_retval_func(void)
{
	unsigned long long value = 0x1234567887654321;
	return value;
}

add a kretprobe event:
echo 'r:myretprobe test_retval_func $retval:x64' > kprobe_events

the trace log:
myretprobe: (retval_open+0x1c/0x2c [test_retval] <- test_retval_func)
arg1=0x87654321