On Tue, Dec 2, 2014 at 4:14 AM, Theodore Ts'o <ty...@mit.edu> wrote: > > Well, if eBPF can get more information without DWARF, that's great. > I'll use whatever I can get, so long as I can do it without DWARF. :-)
eBPF is just an engine. Anyone can develop a userspace bits that will use debug info and/or their favorite language (stap, ktap, dtrace or any other) when right hooks are in place on the kernel side. I'm focusing on restricted C as a way to program it and environments without debug info. > recompile, which is a win. (But since I also do a lot of debug runs > using 32-bit kernels, it would be nice to have things that worked > there as well, which is why in general I'll add tracepoints once I > find that it might be useful to trace a particular function.) Understood. i386 is difficult, since arg passing is using combination of registers(eax,edx,ecx) and stack in non-obvious way, so some trick is needed to get it right without debug info. I'm still trying to solve this one. That's for programs attached to kprobes. Programs that attach to tracepoints will see arguments in a normal way on all archs. Anyway, one step at a time. Easy things first. As one of the crazy things for the future I was thinking about mini-tracepoints. Instead of generating full ftrace_raw_* bodies, generate minimal stubs to collect tracepoint arguments only and invoke programs. In other words move responsibility of TP_STRUCT__entry, TP_fast_assign and TP_printk into the bpf program. On x64 all we need is single stub for all mini-tracepoints. For 32-bit archs all mini-tracepoint stubs will be different to accomodate 32/64-bit argument passing. That will save quite a bit from .text and hopefully more people will enable such tracepoints in production. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
