Author here, yep, I agree, not a bug, just what you get if you start accessing raw stuff instead of stable interfaces and underlying things change (but in this case it was necessary). I mentioned this in the summary in the end.
My understanding is that with BTF + CO-RE, you'll have the flexibility of building your program binary once and it will work on other (BTF+CORE capable) kernel versions without without needing a recompile. But since I had to use lower level methods for stack & pt_regs access, I had to manually add logic for checking kernel structural differences at runtime.
That being said, I have not yet gotten to test if a compiled xcapture binary can just be copied between machines (of the same architecture) and whether it really works as advertised...
How would you recommend learning about eBPF / BTF / CO-RE? I have a basic understanding of what they are, but am not sure where to start for writing eBPF tracing programs, setting them up in production w/ Grafana, etc.
And as a related activity, you could just install the bcc-tools package (on RHEL clones) and check out the /usr/share/bcc/tools directory to see what's already implemented (on latest Ubuntu, these tools seem to be installed in /usr/sbin, etc, but you could "find /usr -name
*bpfcc" to get a list of eBPF tools already installed there (and test/man some more interesting ones).
For the bigger picture and other eBPF uses like networking, I'd get Liz Rice's eBPF book (free download):
But the most valuable resource for me when I took the leap from writing bpftrace one-liners to more sophisticated modern eBPF programs was (and still is) Andrii Nakryiko's blog with examples of modern BPF programming:
Even CO-RE won't help long term. Sure, it'll adjust structure offsets and such for you, but it can't deal with conceptual changes. We need an explicit contractual stable API, at the BPF helper level, not a quivering mound of hacks trying to make unstable APIs magically stable without the work needed to actually stabilize them.
My understanding is that with BTF + CO-RE, you'll have the flexibility of building your program binary once and it will work on other (BTF+CORE capable) kernel versions without without needing a recompile. But since I had to use lower level methods for stack & pt_regs access, I had to manually add logic for checking kernel structural differences at runtime.
That being said, I have not yet gotten to test if a compiled xcapture binary can just be copied between machines (of the same architecture) and whether it really works as advertised...