[DTrace-devel] DTrace-V1-ized 5.15 pushed to github

Nick Alcock nick.alcock at oracle.com
Mon Nov 8 13:01:34 UTC 2021


Tests passed on x86-64 and AArch64 with https://github.com/oracle/dtrace-utils
(1.x-branch-dev branch). (Non-stress tests only: one stress test currently
fails on x86-64. This is unlikely to affect normal use unless you do
something most unusual like chill()ing on all fbt probes at once.)

Pushed to <https://github.com/oracle/dtrace-linux-kernel>, as a branch
with v1 in the name.

This push is of DTrace v1, using a specialized kernel module rather than BPF.
It applies fine to 5.15.1 as well.

This push has seen more changes than most: in addition to little things
like adjusting to upstream changes, dependency fixes and warning fixes,
there are two big changes.

The rewrite of the kallmodsyms commit that we are submitting to the
upstream kernel project has been introduced, reducing memory usage by
about a factor of ten and significantly speeding up reading of
/proc/kallmodsyms (and since DTrace startup reads all of that every
time, this speeds up every DTrace startup slightly).

But, most significantly, we now support the new upstreamed
toolchain-based CTF generation, where CTF is generated by GCC and linked
and deduplicated by GNU ld. If you build a kernel this way, you can
leave out debug info entirely (speeding up the build). The README has
been updated, but it should work automatically if you just ensure that
you have trunk GCC installed (or GCC 12 when it comes out), and at least
binutils 2.36, and have the development packages for binutils installed:
the resulting CTF contains more types and is more correct in the
presence of types with the same name and different definitions. It's
also smaller and builds faster.

If you also remove libdtrace-ctf from your system, you can be sure that
if 'make ctf' works at kernel build time, and DTrace userspace compiles,
your DTrace is using libctf.



More information about the DTrace-devel mailing list