Re: [PATCH bpf-next v1 1/8] bpftool: Dump C from a detached BTF copy

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

On 2026-10-16 2:25 a.m., Alan Maguire wrote:
> On 10/16/26 1:00 AM, Ihor Solodrai wrote:
>> To emit per-record attributes in the C dump, bpftool needs to add decl
>> tags to the BTF it dumps.
>>
>> Modifying the parsed BTF fails for some valid input: libbpf refuses to
>> modify BTF whose header carries unknown nonzero extension bytes, so
>> such a dump would stop with -EOPNOTSUPP.
>>
> 
> Curious here; did you run into such cases? 

Nope.

> ...I would have thought the
> only case would be something like where we have kind layout info in
> a bpftool that does not know about kind layout, but that can't happen
> for an up-to-date bpftool with libbpf that knows about kind layout

I was thinking about forward compat.

Consider a bpftool (with this series) dumping BTF from an even newer
kernel, with data libbpf doesn't know about. has_hdr_extra check
correctly refuses to modify such BTF, and that's what bpftool is
doing.

But if we use the split BTF then this is not an issue, because input
BTF stays read only.

> unless there are issues with out-of-date UAPI headers for btf_header
> or something. Wondering if there's something we need to fix somewhere?
> 
> Thanks!