Re: [RFC 0/4] BTF archive with unmodified pahole+toolchain

[Nick Alcock <nick.alcock@oracle.com>]

On 8 Aug 2025, Arnaldo Carvalho de Melo said:

> On August 7, 2025 11:52:51 PM GMT-03:00, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>On Thu, Aug 7, 2025 at 7:36 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
>
>>> On Thu, Aug 7, 2025, 11:09 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
>>Agree with that as well, but I'm just not easy about "BTF archives" :)
>>The name is too ambitious. Concatenated BTF sections is fine,
>>but let's not make a big deal out of it.
>
> Well, other proposals being discussed would add more metadata to
> traverse these archives, I was just tagging along on the jargon being
> created :-)

We don't actually need *much* more. I think concatenation is less than
ideal simply because it's hard to tell when to stop looking for more
archive members in a concatenated stream.

In the model Jose proposed (more or less the model split BTF is
basically already using), the first member is special, being the parent
and holding most of the shared types, vmlinux etc. Because it's special,
I think we want to be able to identify it even if you, say, take two
sections full of concatenated members and concatenate *them*. Just
relying on straight concat would have all the tools treating the second
vmlinux in that concatenated stream as if it were a module! If there was
a link field (or just a "stop here" bit), it could say "there are no
more members" reliably, or you could ask tools to hunt through
concatenated streams of BTF and tell you which ones in that stream look
like they're vmlinuxes (and all the non-vmlinuxes after those are
modules).

e.g. if you accidentally concatenated

vmlinux -> a -> b -> c

and

vmlinux -> d -> e -> f

You would get

vmlinux -> a -> b -> c -> vmlinux -> d -> e -> f

and it would be nice if the format could at least *tell* that the second
vmlinux *was* a vmlinux without relying on awful hacks like "oh it
contains basic integer or mm types, it must be vmlinux". We can do that
with a link field, or with one single bit saying "stop here", or with a
bit saying "this is the parent, start here". I don't mind which.

We could also do with a single field (long-existing in CTF, which calls
it "cuname") which lets you tell the source of types in different BTF
members. The first, the vmlinux/shared one, is easily identifiable, it's
first: but all the others need to be told apart somehow. Since each
corresponds to a module (in vmlinux) or a compilation unit containing
conflicted types (in userspace CTF), giving it *some* sort of optional
name field in the header seems necessary. I don't really mind what we
call the field: cuname, btf_name, member_name, file_name, anything.

> It was just convenient that an unmodified linker was concatenating
> everything and that from the existing BTF headers I could use a
> preexisting libbpf API, btf__add_btf() merge everything to then use
> another preexisting API, btf__dedup() to get to the same end result.

Yeah.

> I don't see, so far, any other use for a "BTF archive", only as a
> happy intermediate step from a one line change to the kernel to get
> the linker to have the BTF "Compile Units" put together in the same
> order as the DWARF ones for the final merge+dedup.

We use them in userspace. (I think I can converge enough, without BTF
format changes beyond this one, to completely eliminate .ctf in
userspace and just let us use BTF everywhere: but as described in
https://lore.kernel.org/dwarves/87bjpkmak2.fsf@esperi.org.uk/, the BTF
we're using will usually be archives of BTF stuck into a single ELF
section, whether we use a link field or concatenation or some weird
archive format like I used to, it's going to be multiple BTFs-full in a
great many programs).

-- 
NULL && (void)