[Bug translator/23866] dissonance between kernel tracepoint parametrization, lkm vs bpf

["wcohen at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23866

--- Comment #3 from William Cohen <wcohen at redhat dot com> ---
The original bpf tracepoint support only provided a subset of
predefined list of arguments extracted from the tracepoint arguments.
There are some tracepoints by happenstance that have the same set of
target variables available as the systemtap tracepoint versions of the
probes.  Around March 2018 the kernel added the
BPF_PROG_TYPE_RAW_TRACEPOINT which provides an unprocessed array of
the arguments to the tracepoint (ctx->args[i]).  There are a couple of
iovisor bcc file that describe and use the raw tracepoints:

https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md#7-raw-tracepoints

https://github.com/iovisor/bcc/blob/master/tools/runqlat.py
https://github.com/iovisor/bcc/blob/master/tools/runqslower.py

The following blog article provides an example using llvm and bpf
backend to use the bpf raw tracepoint:

https://sysdig.com/blog/the-art-of-writing-ebpf-programs-a-primer/

The above sysdig blog article shows the pointer to the array of 8 byte
entries (ctx->args) is passed in by r1 and outlines how to access the
fields.

-- 
You are receiving this mail because:
You are the assignee for the bug.