Re: [PATCH bpf-next v1 2/4] libbpf: Render decl_tags in btf_dump

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

On 9/16/26 7:12 PM, Alexei Starovoitov wrote:
> On Wed, Sep 16, 2026 at 06:20 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>> BTF_KIND_DECL_TAG is an attribute on a declaration: with kind_flag=0
>> the tag name is the argument of a btf_decl_tag(), and with kind_flag=1
>> it encodes a complete __attribute__.
>>
>> When doing btf_dump, render both forms at every declaration btf_dump
>> emits - a record, a record member and a typedef:
> 
> [...]
> 
>> Every decl tag in vmlinux BTF is a bpf_kfunc or bpf_fastcall tag on a
>> FUNC, which has no declaration in the C output, so generated vmlinux.h
>> does not change.
> 
> iirc the goal of this series is "bpftool btf dump file prog.bpf.o
> format c" and skeletons growing
> __attribute__((btf_decl_tag("contains:..."))) on members.
> Pls say so in the commit log.
> Otherwise it's 200 lines of code for "generated vmlinux.h doesn't
> change".

Hi Alexei, thank you for quick review.

The decl_tags is an old generic gap in btf_dump, which gets closed
with this patch.

The "contains:" is not the use case I had in mind, but yes, it should
be covered as well. The next thing I planned after this lands is a
bpftool change to get rid of:

   #pragma clang attribute push (__attribute__((preserve_access_index)), apply_to = record)

in vmlinux.h, by emitting the attributes explicitly per record.
It's been discussed a long time ago, but never picked up on libbpf /
bpftool side [1].

I'll add a paragraph describing potential use cases in v2.

[1] https://lore.kernel.org/bpf/20240503111836.25275-1-jose.marchesi@oracle.com/

> 
>> +static int btf_dump_cmp_decl_tags(const void *a, const void *b)
>> +{
>> +	const struct decl_tag_desc *x = a, *y = b;
>> +
>> +	if (x->target_id != y->tar
> get_id)
>> +		return x->target_id < y->target_id ? -1 : 1;
>> +	return x->tag_id < y->tag_id ? -1 : 1;
>> +}
> 
> nit: return 0 when equal. cmp(x, x) != 0 is asking for trouble.

For a valid deduped BTF we should never get a duplicate (target_id,
tag_id) pair. I'll see if there is a way to detect this and -EINVAL

> 
>> @@ -220,8 +258,18 @@ static int btf_dump_resize(struct btf_dump *d)
>>  		err = btf_dump_mark_referenced(d, t);
>>  		if (err)
>>  			return err;
>> +
>> +		if (btf_is_decl_tag(t)) {
>> +			err = btf_dump_push_decl_tag(d, i, t);
>> +			if (err)
>> +				return err;
>> +		}
>>  	}
> 
> \edited robot voice
> 
> On either error d->last_id is not advanced but d->decl_tags_cnt keeps
> whatever was pushed so far, so the next btf_dump__dump_type() walks
> the same ids again and pushes the same tags twice -> duplicated
> __attribute__ in the output ?

Yeah, my clanker flagged this too. I decided a mid-dump retry on error
is a weird case to support in the context of btf_dump, so ignored it.

Andrii, do you have an opinion?



> 
> pw-bot: cr