Re: [PATCH v2 bpf-next 03/18] libbpf: Support moving permuted BTF types into split BTF

[Alan Maguire <alan.maguire@oracle.com>]

On 10/09/2026 10:37, Eduard Zingerman wrote:
> On Tue, 2026-09-01 at 17:57 +0100, Alan Maguire wrote:
>> Extend btf__permute() with an optional transfer mode.  Type-map entries
>> marked with BTF_PERMUTE_ID_TRANSFER are removed from the input BTF and
>> copied into a newly-created split BTF returned through
>> btf_permute_opts.transfer_btf.
>> 
>> While moving types, remap type IDs for both retained and transferred
>> types, preserving split-BTF references to the parent BTF where needed.
>> 
>> String handling has to be done carefully as we do not want to have
>> strings that only exist in the split BTF to impose a cost on the base.
>> Copy referenced strings locally first, compact the parent string table
>> after the moved types are gone, rebase split-string offsets, and compact
>> the split string table.  This leaves strings exclusively needed by moved
>> types in the split BTF while retaining shared strings in the parent.
>> This will be important later for function names of inline-only functions;
>> these should not take up space in base BTF but should have strings in
>> inline BTF only.
>> 
>> This all provides the support needed to place inline-only BTF
>> in a separate BTF section, which resolve_btfids will use later.
>> 
>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>> Assisted-by: Codex (GPT-5)
>> ---
> 
> Hi Alan,
> 
> What do you think about an alternative approach to permute and
> resolve_btfids changes described below?
> 
> Instead of specifying a permute mapping can just rebuild two BTFs from
> scratch: base BTF w/o LOC types and .BTF.inline BTF with LOC types only.
> This would give strings dedup / compaction for free and would not
> require further changes in libbpf.
> 
> Concretely, commit [1] (branch [2]) uses the following steps:
> - Traverse all types reachable from LOC_PARAM, LOC_PROTO, LOCSEC
>   entries and mark them as having LOC color.
> - Traverse all types reachable from the remaining types
>   and mark them as having MAIN or SHARED colors.
> - Create a new base BTF object and copy all MAIN/SHARED types there.
> - Create a new .BTF.inline object with base set to the new base BTF
>   object, and copy all LOC types there.
> 
> This seem to be on par with your current branch with regards to
> speed / memory usage:
> 
> │ Version                 │ Elapsed, mean ± SEM │ Peak RSS, mean │
> ├─────────────────────────┼─────────────────────┼────────────────┤
> │ Original permute        │ 338.8 ± 8.1 ms      │ 71.20 MiB      │
> │ Proposed                │ 284.1 ± 10.2 ms     │ 70.10 MiB      │
> 
> But seems a tad simpler in terms of implementation (~ -250 lines of code).
> 
> I also changed how LOC-only FUNC objects are identified, by using a
> generic type graph traversal utility function (btf_mark_reachable()).
> This is a bit less code and opens a possibility to move some more
> types to .BTF.inline:
> 
> │ Section     │ Before (bytes) │ After          │ Change   │
> ├─────────────┼────────────────┼────────────────┼──────────┤
> │ .BTF        │ 5,207,078      │ 5,047,510      │ −159,568 │
> │ .BTF.inline │ 9,867,471      │ 10,027,039     │ +159,568 │
> 
> This is the same change, but when allowed to move regular types from
> base to .BTF.inline, if those types are not used by base.
> 
> [1] https://github.com/eddyz87/bpf/commit/abe515962632ad51f8aa50e44354b88f80bbd606
> [2] https://github.com/eddyz87/bpf/tree/resolve-btf-ids-btf-inline
>     (tests commit is 100% slop, please ignore it).
> 

Thanks for doing this Eduard, it looks like a really neat solution! The permutation
approach - which is really a permute and a segmentation - felt a bit clunky and
doesn't feel like it belongs in libbpf really (it's a very specific problem).

I'll play around with this a bit more, and with your permission maybe we could
include it in the kbuild inline series? (I'm splitting up the work into the
libbpf/kernel location support needed for pahole, and a followup to add the
location info)

Thanks again!

Alan