On Sat, 3 Feb 2018 22:38:17 +0900 Masami Hiramatsu <mhiramat@xxxxxxxxxx> 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. > > 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. 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. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|