Re: [RFC PATCH v7 3/7] tools/resolve_btfids: Add --btf_sort option for BTF name sorting

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 11/21/25 7:36 AM, Donglin Peng wrote:
> On Fri, Nov 21, 2025 at 5:34 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> On 11/18/25 7:15 PM, Donglin Peng wrote:
>>> From: Donglin Peng <pengdonglin@xiaomi.com>
>>>
>>> This patch introduces a new --btf_sort option that leverages libbpf's
>>> btf__permute interface to reorganize BTF layout. The implementation
>>> sorts BTF types by name in ascending order, placing anonymous types at
>>> the end to enable efficient binary search lookup.
>>
>> [...]
>>
>> Hi Dongling.
>>
>> Thanks for working on this, it's a great optimization. Just want to
>> give you a heads up that I am preparing a patchset changing
>> resolve_btfids behavior.
> 
> Thanks. I'm curious about the new behavior of resolve_btfids. Does it
> replace pahole and generate the sorted .BTF data directly from the
> DWARF data? Also, does its sorting method differ from the cmp_type_names
> approach mentioned above — specifically, does it place named types
> before all anonymous types? I'm asking because the search method
> needs to be compatible with this sorting approach.

No, replacing pahole entirely isn't really feasible, and unnecessary.

TL;DR is that resolve_btfids will also do kernel-specific btf2btf
transformations. The sorting feature is independent, it's relevant
only in that it is also a btf2btf transformation and will be included
in the pipeline.

I described the approach here:
https://lore.kernel.org/dwarves/ba1650aa-fafd-49a8-bea4-bdddee7c38c9@linux.dev/


> 
>>
>> In particular, instead of updating the .BTF_ids section (and now with
>> your and upcoming changes the .BTF section) *in-place*, resolve_btfids
>> will only emit the data for the sections. And then it'll be integrated
>> into vmlinux with objcopy and linker. We already do a similar thing
>> with .BTF for vmlinux [1].
>>
>> For your patchset it means that the parts handling ELF update will be
>> unnecessary.
>>
>> Also I think the --btf_sort flag is unnecessary. We probably want
>> kernel BTF to always be sorted in this way. And if resolve_btfids will
>> be handling more btf2btf transformation, we should avoid adding a
>> flags for every one of them.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/scripts/link-vmlinux.sh#n110
>>