On 29/09/2026 19:25, Alan Maguire wrote:
> The idea is close to what you had; we have a .BTF.link / .BTF.inline.link ELF
> section which consists of:
>
> #define BTF_LINK_SHA256_LEN 32
>
> /*
> * A .BTF.link or .BTF.inline.link section identifies the module which
> * carries a vmlinux BTF section. The module name is NUL terminated and the
> * field is padded to __MODULE_NAME_LEN.
> */
> struct btf_link {
> char module_name[__MODULE_NAME_LEN];
> u8 sha256[BTF_LINK_SHA256_LEN];
> u32 btf_size;
> } __packed;
Thanks, this works well for this series too, and it also covers both
points of your first mail. v4 has it:
https://lore.kernel.org/bpf/[email protected]/
struct btf_link has this layout, and the kernel now takes the name of
the module to load from it: request_module() and the module notifier use
module_name instead of a hard-coded "btf_vmlinux" (patch 4/12).
> The link section is populated at the same time resolve_btfids populates the
> .BTF_ids section;
> we add support to resolve_btfids for a --btf_link option of the form
>
> --btf_link <section>:<module>:<raw-btf-file>
>
> So in your case it will be
>
> --btf_link .BTF:btf_vmlinux:vmlinux.BTF
That is what link-vmlinux.sh passes to the final --patch_btfids now,
with .tmp_vmlinux1.BTF as the file, which gen-btf.sh keeps for it with
=m (patch 12/12). The printf code in gen-btf.sh is gone.
Filling the record in at the end also removed v3's placeholder object
for the first link: the zeroed record is now defined in C next to
struct btf_link, so it has its final size in every link, and the size
check in resolve_btfids also catches the kernel and the tool disagreeing
on the layout.
> resolve_btfids is written to support multiple --btf_link options, so
> whichever work lands
> first could add the support that the other series uses. Hope this helps,
Your patch is 10/12, without the inline BTF context, which I will
leave to a separate patch series later. I reworded its subject and
changelog and made a few small changes, all listed in the bracketed
note above my Signed-off-by. Please check that you are fine with it in
that form.
Tested with 32- and 64-bit, little- and big-endian objects, also with
two --btf_link options in one run, and on x86-64 and i386 =m kernels,
where .BTF.link matches the BTF in btf_vmlinux.ko.
Jay