On Wed, Aug 9, 2023 at 4:16 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > On Wed, 9 Aug 2023 12:29:13 +0200 > Florent Revest <revest@xxxxxxxxxxxx> wrote: > > > + * tracer, define the default(pt_regs compatible) ftrace_regs. > > > + */ > > > +#if !defined(CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS) || !defined(CONFIG_FUNCTION_TRACER) > > > > I wonder if we should make things simpler with: > > > > #if defined(HAVE_PT_REGS_COMPAT_FTRACE_REGS) || !defined(CONFIG_FUNCTION_TRACER) > > > > And remove the ftrace_regs definitions that are copy-pastes of this > > block in arch specific headers. Then we can enforce in a single point > > that HAVE_PT_REGS_COMPAT_FTRACE_REGS holds. > > Here, the "HAVE_PT_REGS_COMPAT_FTRACE_REGS" does not mean that the > ftrace_regs is completely compatible with pt_regs, but on the memory > it wraps struct pt_regs (thus we can just cast the type). But in practice I think that all architectures that chose to wrap a pt_regs in their ftrace_regs also do: +#define ftrace_regs_get_instruction_pointer(fregs) \ + instruction_pointer(ftrace_get_regs(fregs)) +#define ftrace_regs_get_argument(fregs, n) \ + regs_get_kernel_argument(ftrace_get_regs(fregs), n) +#define ftrace_regs_get_stack_pointer(fregs) \ + kernel_stack_pointer(ftrace_get_regs(fregs)) +#define ftrace_regs_return_value(fregs) \ + regs_return_value(ftrace_get_regs(fregs)) +#define ftrace_regs_set_return_value(fregs, ret) \ + regs_set_return_value(ftrace_get_regs(fregs), ret) +#define ftrace_override_function_with_return(fregs) \ + override_function_with_return(ftrace_get_regs(fregs)) +#define ftrace_regs_query_register_offset(name) \ + regs_query_register_offset(name) And are just careful to populate the fields that let these macros work. So maybe these could be factorized... But anyway, I'm not particularly a super fan of the idea and I don't think it should necessarily fit in that series. It's just something that crossed my mind, if you're not a fan then we should probably not do it ;)
