On Fri, Jul 22, 2022 at 05:41:20PM -0400, Steven Rostedt wrote: > On Fri, 22 Jul 2022 23:05:19 +0200 > Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > ok, I think we could use that, I'll check > > > > > > > > But other than that, we don't need infrastructure to hide any mcount/fentry > > > locations from ftrace. Those were add *for* ftrace. > > > > I think I understand the fentry/ftrace equivalence you see, I remember > > the perl mcount script ;-) > > It's even more than that. We worked with the compiler folks to get fentry > for ftrace purposes (namely to speed it up, and not rely on frame > pointers, which mcount did). fentry never existed until then. Like I said. > fentry was created *for* ftrace. And currently it's x86 specific, as it > relies on the calling convention that a call does both, push the return > address onto the stack, and jump to a function. The blr > (branch-link-register) method is more complex, which is where the > "patchable" work comes from. > > > > > still I think we should be able to define function that has fentry > > profile call and be able to manage it without ftrace > > > > one other thought.. how about adding function that would allow to disable > > function in ftrace, with existing FTRACE_FL_DISABLED or some new flag > > > > that way ftrace still keeps track of it, but won't allow to use it in > > ftrace infra > > Another way is to remove it at compile time from the mcount_loc table, and > add it to your own table. I take it, this is for bpf infrastructure code hm, perhaps we could move it to separate object and switch off -mrecord-mcount for it, I'll check > and not for any code that's in the day to day processing of the kernel, > right? yes, it's bpf specific code thanks, jirka
