Re: [PATCH bpf-next v2 04/13] resolve_btfids: Introduce finalize_btf() step

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

On 1/19/26 4:13 PM, Eduard Zingerman wrote:
> On Fri, 2026-01-16 at 12:16 -0800, Ihor Solodrai wrote:
>> Since recently [1][2] resolve_btfids executes final adjustments to the
>> kernel/module BTF before it's embedded into the target binary.
>>
>> To keep the implementation simple, a clear and stable "pipeline" of
>> how BTF data flows through resolve_btfids would be helpful. Some BTF
>> modifications may change the ids of the types, so it is important to
>> maintain correct order of operations with respect to .BTF_ids
>> resolution too.
>>
>> This patch refactors the BTF handling to establish the following
>> sequence:
>>   - load target ELF sections
>>   - load .BTF_ids symbols
>>     - this will be a dependency of btf2btf transformations in
>>       subsequent patches
>>   - load BTF and its base as is
>>   - (*) btf2btf transformations will happen here
>>   - finalize_btf(), introduced in this patch
>>     - does distill base and sort BTF
>>   - resolve and patch .BTF_ids
>>
>> This approach helps to avoid fixups in .BTF_ids data in case the ids
>> change at any point of BTF processing, because symbol resolution
>> happens on the finalized, ready to dump, BTF data.
>>
>> This also gives flexibility in BTF transformations, because they will
>> happen on BTF that is not distilled and/or sorted yet, allowing to
>> freely add, remove and modify BTF types.
>>
>> [1] https://lore.kernel.org/bpf/20251219181321.1283664-1-ihor.solodrai@linux.dev/
>> [2] https://lore.kernel.org/bpf/20260109130003.3313716-1-dolinux.peng@gmail.com/
>>
>> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
>> ---
> 
> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> 
>> @@ -1099,12 +1116,22 @@ int main(int argc, const char **argv)
>>  	if (obj.efile.idlist_shndx == -1 ||
>>  	    obj.efile.symbols_shndx == -1) {
>>  		pr_debug("Cannot find .BTF_ids or symbols sections, skip symbols resolution\n");
>> -		goto dump_btf;
>> +		resolve_btfids = false;
>>  	}
>>  
>> -	if (symbols_collect(&obj))
>> +	if (resolve_btfids)
>> +		if (symbols_collect(&obj))
>> +			goto out;
> 
> Nit: check obj.efile.idlist_shndx and obj.efile.symbols_shndx inside symbols_collect()?
>      To avoid resolve_btfids flag and the `goto dump_btf;` below.

Hi Eduard, thank you for review.

The issue is that in case of .BTF_ids section absent we have to skip
some of the steps, specifically:
  - symbols_collect()
  - sequence between symbols_resolve() and dump_raw_btf_ids()

It's not an exit condition, we still have to do load/dump of the BTF.

I tried in symbols_collect():

	if (obj.efile.idlist_shndx == -1 || obj.efile.symbols_shndx == -1)
		return 0;

But then, we either have to do the same check in symbols_resolve() and
co, or maybe store a flag in the struct object.  So I decided it's
better to have an explicit flag in the main control flow, instead of
hiding it.

lmk if you had something else in mind


> 
>> +
>> +	if (load_btf(&obj))
>>  		goto out;
>>  
>> +	if (finalize_btf(&obj))
>> +		goto out;
>> +
>> +	if (!resolve_btfids)
>> +		goto dump_btf;
>> +
>>  	if (symbols_resolve(&obj))
>>  		goto out;
>>