Re: [PATCH bpf-next v2 4/4] resolve_btfids: change in-place update with raw binary output

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

On 11/27/25 7:20 PM, Donglin Peng wrote:
> On Fri, Nov 28, 2025 at 2:53 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> [...]
>>
>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
>> index bac22265e7ff..ec7e2a7721c7 100644
>> --- a/tools/testing/selftests/bpf/Makefile
>> +++ b/tools/testing/selftests/bpf/Makefile
>> @@ -4,6 +4,7 @@ include ../../../scripts/Makefile.arch
>>  include ../../../scripts/Makefile.include
>>
>>  CXX ?= $(CROSS_COMPILE)g++
>> +OBJCOPY ?= $(CROSS_COMPILE)objcopy
>>
>>  CURDIR := $(abspath .)
>>  TOOLSDIR := $(abspath ../../..)
>> @@ -716,6 +717,10 @@ $(OUTPUT)/$(TRUNNER_BINARY): $(TRUNNER_TEST_OBJS)                  \
>>         $$(call msg,BINARY,,$$@)
>>         $(Q)$$(CC) $$(CFLAGS) $$(filter %.a %.o,$$^) $$(LDLIBS) $$(LLVM_LDLIBS) $$(LDFLAGS) $$(LLVM_LDFLAGS) -o $$@
>>         $(Q)$(RESOLVE_BTFIDS) --btf $(TRUNNER_OUTPUT)/btf_data.bpf.o $$@
>> +       $(Q)if [ -f $$@.btf_ids ]; then \
>> +               $(OBJCOPY) --update-section .BTF_ids=$$@.btf_ids $$@; \
> 
> I encountered a resolve_btfids self-test failure when enabling the
> BTF sorting feature, with the following error output:
> 
> All error logs:
> resolve_symbols:PASS:resolve 0 nsec
> test_resolve_btfids:PASS:id_check 0 nsec
> test_resolve_btfids:PASS:id_check 0 nsec
> test_resolve_btfids:FAIL:id_check wrong ID for T (7 != 5)
> #369     resolve_btfids:FAIL
> 
> The root cause is that prog_tests/resolve_btfids.c retrieves type IDs
> from btf_data.bpf.o and compares them against the IDs in test_progs.
> However, while the IDs in test_progs are sorted, those in btf_data.bpf.o
> remain in their original unsorted state, causing the validation to fail.
> 
> This presents two potential solutions:
> 1. Update the relevant .BTF.* section datas in btf_data.bpf.o, including
>     the .BTF and .BTF.ext sections
> 2. Modify prog_tests/resolve_btfids.c to retrieve IDs from test_progs.btf
>     instead. However, I discovered that test_progs.btf is deleted in the
>     subsequent code section.
> 
> What do you think of it?

Within resolve_btfids it's clear that we have to update (sort in this
case) BTF first, and then resolve the ids based on the changed BTF.

As for the test, we should probably change it to become closer to an
actual resolve_btfids use-case. Maybe even replace or remove it.

resolve_btfids operates on BTF generated by pahole for
kernel/module. And the .BTF_ids section makes sense only in kernel
space AFAIU (might be wrong, let me know if I am).

And in this test we are using BTF produced by LLVM for a BPF program,
and then create a .BTF_ids section in a user-space app (test_progs /
resolve_btfids.test.o), although using proper kernel macros.

By the way, the test was written more than 5y ago [1], so it might be
outdated too.

I think the behavior that we care about is already indirectly tested
by bpf_testmod module tests, with custom BPF kfuncs and BTF_ID_*
declarations etc. If resolve_btfids is broken, those tests will fail.

But it's also reasonable to have some tests targeting resolve_btfids
app itself, of course. This one doesn't fit though IMO.

I'll try to think of something.

[1] https://lore.kernel.org/bpf/20200703095111.3268961-10-jolsa@kernel.org/


> 
> Thanks,
> Donglin
> 
>> +       fi
>> +       $(Q)rm -f $$@.btf_ids $$@.btf
>>         $(Q)ln -sf $(if $2,..,.)/tools/build/bpftool/$(USE_BOOTSTRAP)bpftool \
>>                    $(OUTPUT)/$(if $2,$2/)bpftool
>>
>> --
>> 2.52.0
>>