On Thu, Oct 24, 2024 at 10:21 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > 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 > Indeed, after updating to the latest pahole master now I get .BTF.base, very nice. > 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? Makes sense, please send the patch. > > >> > >> 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
