On Fri, 23 Oct 2020 13:03:22 -0700 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > Basically, maybe ftrace subsystem could provide a set of APIs to > prepare a set of functions to attach to. Then BPF subsystem would just > do what it does today, except instead of attaching to a specific > kernel function, it would attach to ftrace's placeholder. I don't know > anything about ftrace implementation, so this might be far off. But I > thought that looking at this problem from a bit of a different angle > would benefit the discussion. Thoughts? I probably understand bpf internals as much as you understand ftrace internals ;-) Anyway, what I'm currently working on, is a fast way to get to the arguments of a function. For now, I'm just focused on x86_64, and only add 6 argments. The main issue that Alexei had with using the ftrace trampoline, was that the only way to get to the arguments was to set the "REGS" flag, which would give a regs parameter that contained a full pt_regs. The problem with this approach is that it required saving *all* regs for every function traced. Alexei felt that this was too much overehead. Looking at Jiri's patch, I took a look at the creation of the bpf trampoline, and noticed that it's copying the regs on a stack (at least what is used, which I think could be an issue). For tracing a function, one must store all argument registers used, and restore them, as that's how they are passed from caller to callee. And since they are stored anyway, I figure, that should also be sent to the function callbacks, so that they have access to them too. I'm working on a set of patches to make this a reality. -- Steve
