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 <[email protected]> > 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, Eduard ...
