On Sun, 5 Nov 2023 18:33:01 -0500 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Mon, 6 Nov 2023 00:17:34 +0100 > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > Changelog nor code made it clear this was partial anything. So this is > > still the partial thing? > > > > Can we then pretty clear clarify all that, and make it clear which regs > > are in there? Because when I do 'vim -t ftrace_regs' it just gets me a > > seemingly pointless wrapper struct, no elucidating comments nothingses. > > I agree it should be better documented (like everything else). The > ftrace_regs must have all the registers needed to produce a function's > arguments. For x86_64, that would be: > > rdi, rsi, rdx, r8, r9, rsp > > Basically anything that is needed to call mcount/fentry. Oops, I found I missed to save rsp. let me update it. Anyway, this will be defined clearly. ftrace_regs needs to be a partial set of registers related to the (kernel) function call. - registers which is used for passing the function parameters in integer registers and stack pointer (for parameters on memory). - registers which is used for passing the return values. - call-frame-pointer register if exists. So for x86-64, - rdi, rsi, rcx, rdx, r8, r9, and rsp - rax and rdx - rbp (BTW, why orig_rax is cleared?) > But yes, it's still partial registers but for archs that support > FTRACE_WITH_REGS, it can also hold all pt_regs which can be retrieved > by the arch_ftrace_get_regs(), which is why there's a pt_regs struct in > the x86 version. But that's not the case for arm64, as > arch_ftrace_get_regs() will always return NULL. The major reason of the DYNAMIC_FTRACE_WITH_REGS is livepatch and kprobe on ftrace (if kprobe puts probe on the ftrace address, it uses ftrace instead of breakpoint). Thank you, -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
