> On Sat, 3 Feb 2018 22:38:17 +0900> Masami Hiramatsu <mhiramat@kernel.org> wrote:> > > This seems very similar feature of what kprobe-based event does.> > It is similar, but not the same as kprobes. It only focuses on> functions and their arguments, and should not require any disassembling> (no knowledge of regs required). Any need to see anything within the> function will still require kprobe based help.

Yes, I see that point.

> > Earlier version of kprobe-based event supported Nth argument, but I decided> > to drop it because we can not ensure the "function signature" from kernel> > binary. It has been passed to "perf probe", so that we can define line-level> > granularity. > > Sure, and if we get a wrong function, which can happen, the code is set> up not to break anything. You only get garbage output.> > > > > Of course if it is easy to support "argN" again as it does if the arch's> > calling convention is clearly stated. (and now kprobe is based on ftrace> > if it is on the entry of functions)> > > > So my question is, what is the difference of those from the user perspective?> > Only event syntax is a problem?> > I'm very confusing...> > Again, this is not a kprobe replacement. It is somewhat of a syntax> issue. I want this to be very simple and not need a disassembler. For> indexing of structures one may use gdb, but that's about it. You could> get the same info from counting what's in a structure itself.

OK, so it is a simpler version of function event...

> I based some of the code from kprobes too. But I wanted this to be> simpler, and as such, not as powerful as kprobes. More of a "poor mans"> kprobe ;-) Where you are limited to functions and their arguments. If> you need more power, switch to kprobes. In other words, its just an> added stepping stone.> > Also, this should work without kprobe support, only ftrace, and function> args from the arch.

Hmm, but implementation seems very far from current probe events, we needto consider how to unify it. Anyway, it is a very good time to do, becauseI found current probe-event fetch method is not good with retpoline/IBRS,it is full of indirect call.

I would like to convert it to eBPF if possible. It will be good for theperformance with JIT, and we can collaborate on the same code with BPFpeople.