LWN: Comments on "Another attempt to address the tracepoint ABI problem"

Another attempt to address the tracepoint ABI problem

jikos — Wed, 01 Nov 2017 16:25:49 +0000

That makes is super-fragile though. GCC does a lot of optimizations on static functions that break x86 ABI (IPA-RA for example).

Another attempt to address the tracepoint ABI problem

SelaLWN — Wed, 01 Nov 2017 14:33:35 +0000

It's ABI-sensitive, but if a language or runtime decides to pass arguments in a heap location or something that's not the standard ABI, it won't work (i.e. debuginfo isn't used).

Another attempt to address the tracepoint ABI problem

jikos — Tue, 31 Oct 2017 15:39:00 +0000

BTW how does that tool access the function parameters? Does it assume that x86_64 ABI is always being followed, or do you require DWARF2 debuginfo data for those?

Another attempt to address the tracepoint ABI problem

SelaLWN — Sat, 28 Oct 2017 09:15:56 +0000

There is already support for running a BPF program when an arbitrary kernel function is called, with access to that function's arguments -- this can be done using kprobes. Indeed, in BCC (https://github.com/iovisor/bcc) we have a large collection of BPF-based tools that rely on tracepoints when available, and kprobes when not. Over the last 1.5 years, we had multiple tools break because of intentional and unintentional changes to kernel functions when using kprobes; not so much when using tracepoints.

Another attempt to address the tracepoint ABI problem

jhoblitt — Fri, 27 Oct 2017 17:43:49 +0000

It sounds like there are conflicting use cases for tracepoints: kernel debugging and exporting data to userspace. The powertop example begs the question of why a tracing framework is needed to collect process statics (looks like wake ups). Couldn't that be accomplished by enhanced process statics that could be exposed via sysfs when enabled?

Another attempt to address the tracepoint ABI problem

davecb — Fri, 27 Oct 2017 17:30:31 +0000

We had a variant of that in Solaris, specifically in the libraries, which had to be both stable and changable (;-))

David J. Brown attached version numbers to function entry points, like SUNW_1.1 (for something public: SUNWprivate for everything else). If the entry point changed, even if the function signature was the same, the number got bumped to SUNW_1.2.

If a tracepoint points to a function to attach a BPF script to, the script for that tracepoint can check if the function version has changed, and if it has, the person using it can go and do a "git blame" hunt to see what they need to do.

Another attempt to address the tracepoint ABI problem

josh — Fri, 27 Oct 2017 15:14:27 +0000

> Instead, support will be added to make it easy for an application to attach a BPF script to any function in the kernel, with access to that function's arguments. That should give tools access to the information they need, and may make it possible to (eventually) remove many of the existing explicit tracepoints.

> Arnd Bergmann asked what would happen if a popular script breaks as the result of the removal of a function; Torvalds replied that it would not see it as a regression that needs to be fixed.

Sounds like the "attach a BPF script to any function" mechanism would have an ABI like that of init_module or finit_module: the thing it loads lives inside the kernel, making it fall under the kernel's internal ABI (lack of) guarantees rather than the userspace ABI guarantees.