Tracepoints with BPF

Posted Apr 14, 2016 1:50 UTC (Thu) by dw (guest, #12017)
Parent article: Tracepoints with BPF

Reading about the proliferation of methods to introspect the kernel's structure leaves me wondering if Linux couldn't borrow something like FreeBSD CTF for uniformly describing kernel types.

CTF is just a compact version of DWARF that minimally describes function and structures, it was introduced for DTrace, but recently there have been attempts to extend it to more areas where userland needs the same information, like ps and netstat (e.g. https://wiki.freebsd.org/SummerOfCode2014Ideas#Use_CTF_da... )

Tracepoints with BPF

Posted Apr 15, 2016 17:51 UTC (Fri) by nix (subscriber, #2304) [Link]

There is already code available to do precisely that, meant for DTrace for Linux but GPLv2-licensed: <https://oss.oracle.com/git/?p=linux-uek.git;a=tree;f=scri...>. This code depends on a port/extension of the old Solaris libctf library, which has been dual-licensed under the GPLv2 for the purpose: <https://oss.oracle.com/git/?p=libdtrace-ctf.git;a=summary> (despite its name this is not DTrace-specific: I simply wanted to use a different name from the old Solaris library to indicate that it isn't precisely compatible at the data-structure level and you can't expect to use Solaris-generated CTF with it. It has a few new features, too, such as the ability to encode the types of global variables.)

The types are deduplicated, gzip-compressed, and (in conjunction with the modified Makefile.modpost in the parent directory in that git tree) written to new ELF sections in the kernel modules, with types shared between more than one module or between modules and the core kernel written into a new, empty-but-for-types 'ctf.ko' module, whose contained CTF is meant to be set as the parent of the other CTFs at runtime, so that types depending on or pointing to those shared types will be correctly represented. The core UEK4 kernel and shared types uses about a megabyte: all 3000+ modules' types come to about 3.5MiB all told.

(Caveat: this code has at least one known bug in that it generates wrong type graphs under some, rare situations. I have a significant rewrite of the deduplicator planned that will fix this, but it's a rare enough problem that I haven't done it yet... and to be honest there are plenty of things that CTF just can't represent which force us to leave the occasional thing out of the type graph, still well under .001% of types, but still, there are limits to how accurate we can get. See the blacklists in that directory and the commit logs associated with them.)

I would have no objection whatsoever to people using this code, fixing it, enhancing it, contributing improvements back, etc. (DWARF4 support is one big missing piece, and I've only really tested it with GCC 4.4, 4.8 and 4.9, so other versions might well generate debuginfo that it needs adjustments to comprehend. That's the nature of these sorts of things, really.)