bpf+tracing next steps. Was: [PATCH v9 tip 3/9] tracing: attach BPF programs to kprobes

[Alexei Starovoitov <ast@plumgrid.com>]

On 3/22/15 7:17 PM, Masami Hiramatsu wrote:
> (2015/03/23 3:03), Alexei Starovoitov wrote:
> 
>> User space tools that will compile ktap/dtrace scripts into bpf might
>> use build-id for their own purpose, but that's a different discussion.
> 
> Agreed.
> I'd like to discuss it since kprobe event interface may also have same
> issue.

I'm not sure what 'issue' you're seeing. My understanding is that
build-ids are used by perf to associate binaries with their debug info
and by systemtap to make sure that probes actually match the kernel
they were compiled for. In bpf case it probably will be perf way only.
Are you interested in doing something with bpf ? ;)
I know that Jovi is working on clang-based front-end, He Kuang is doing
something fancy and I'm going to focus on 'tcp instrumentation' once
bpf+kprobes is in. I think these efforts will help us make it
concrete and will establish a path towards bpf+tracepoints
(debug tracepoints or trace markers) and eventual integration with perf.
Here is the wish-list (for kernel and userspace) inspired by Brendan:
- access to pid, uid, tid, comm, etc
- access to kernel stack trace
- access to user-level stack trace
- kernel debuginfo for walking kernel structs, and accessing kprobe
entry args as variables
- tracing of uprobes
- tracing of user markers
- user debuginfo for user structs and args
- easy to use language
- library of scripting features
- nice one-liner syntax

I think there is a lot of interest in bpf+tracing and would be good to
align the efforts.