On 24/10/2024 17:53, Andrii Nakryiko wrote: > On Thu, Oct 24, 2024 at 7:10 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: >> >> 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. > > It's not, strictly speaking, needed, but it might be a good thing to > do this anyways to avoid unnecessary rebuilding of kernel modules > (always a good thing). > > But at the very least we should enable it for bpf_testmod* in BPF > selftests. Can we start with that? > The good news is that already happens, provided you have the updated pahole to handle distilled base generation. After building selftests I see $ objdump -h bpf_testmod.ko |grep BTF 7 .BTF_ids 000001c8 0000000000000000 0000000000000000 00002c50 2**0 50 .BTF 000036f4 0000000000000000 0000000000000000 0006e048 2**0 51 .BTF.base 000004cc 0000000000000000 0000000000000000 0007173c 2**0 Given that these changes are in the master branch of dwarves, I _think_ we should be testing with this in CI already, or will be imminently at least. I'll do some retesting at my end to ensure no regressions are observed in test results when using distilled base BTF. One thing I neglected to do was to send a patch that describe .BTF.base in Documentation/bpf/btf.rst ; we discuss .BTF_ids there so I think it'd be good to mention .BTF.base there too? >> >> 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, for the list. > > I think we should prioritize 3 (and 1, of course), as you said, any > BTF extension would be blocked on this (as far as I'm concerned at > least). I wouldn't delay until we actually add a new BTF kind to land > BTF header modifications, that would just delay future work > unnecessarily. > Sounds good! I'll prioritize 3; it was pretty close last time we discussed it I think. Alan
