hey Andrii On 23/10/2024 01:08, Andrii Nakryiko wrote: > Hey Alan, > > There were a few BTF-related features you've been working on, and I > realized recently that I don't remember exactly where we ended up with > them and whether there is anything blocking those features. So instead > of going on a mailing list archeology trip, I decided to lazily ask > you directly :) > > Basically, at some point we were discussing and reviewing BTF > extensions to have a minimal description of BTF types sizes (fixed and > per-item length). What happened to it? Did we decide it's not > necessary, or is it still in the works? Yeah, it's still in the works; more on that below.. > > Also, distilled BTF stuff. We landed libbpf-side API (and I believe > the kernel-side changes went in as well, right?), but I don't think we > enabled this functionality for kernel builds, is that right? What's > missing to have relocatable BTF inside kernel modules? Pahole changes? > Has that landed? > The pahole changes are in, and will be available in the imminent v1.28 release. Distilled BTF will however only be generated for out-of-tree module builds, since it's not needed for kernels where vmlinux + module are built at the same time. Here's the set of BTF things I think we've discussed and folks have talked about wanting. I've tried to order them based upon dependencies, but in most cases a different ordering is possible. 1. Build vmlinux BTF as a module (support CONFIG_DEBUG_INFO_BTF=m). This one helps the embedded folks as modules can be on a separate partition, and a very large vmlinux is a problem in that environment apparently. Plus we can do module compression, and I did some measurements and vmlinux BTF shrinks from ~7Mb to ~1.5Mb when gzip-compressed. This is sort of a dependency for 2. all global variables in BTF. Stephen Brennan added support to pahole, but we haven't switched the feature on yet in Makefile.btf. Needs more testing and for some folks the growth in vmlinux BTF (~1.5Mb) may be an issue, hence a soft dependency on 1. 3. BTF header modifications to support kind layout. I've been waiting for the need for a new BTF kind to add this, but that's not strictly needed. But that brings us on to 4. Augmenting BTF representations to support site-specific info (including function addresses). We talked about this a bit with Yonghong at plumbers. Will probably require new kind(s) so 3 should likely be done first. May also need some special handling so as not to expose function addresses to unprivileged users. So I think 1 is possibly needed before 2, and I'm working on an RFC for 1 which I hope to get sent out next week (been a bit delayed working on the pahole release). 3 would need to be done before 4, or ideally any other series that introduced new BTF kinds. So that's the set of things I'm aware of - there may be other needs of course - but the order 1-4 was roughly how I was thinking we could attack it. 1 and 2 don't require core BTF changes, so are less disruptive. We'd got pretty far down the road with an earlier version of 3, so if anyone needed it sooner than I get to it, I'd be happy to help of course. Thanks! Alan
