Re: [PATCH bpf-next v3 2/3] bpftool: Preserve unsigned enum values in data dumps

[Andrii Nakryiko]

On Thu, Nov 5, 2026 at 5:03 PM Hungyu Lin <dennylin0707@xxxxxxxxx> wrote:
>
> > how old by now are those btf produces that do not emit kflag=1 for
> > signed enums? should we even care at this point or just assume that
> > kflag is set correctly?
>
> LLVM 14 and earlier, and pahole before 1.24, for example. Signed
> enum kflag support was added in pahole 1.24 (August 2022) and
> LLVM 15 (September 2022), about four years ago.
>
> libbpf still clears enum kflag when loading BTF into kernels without
> enum64 support, though. bpftool map dump reads that BTF back from
> the kernel, so this also happens with newer compilers.

BTF enum64 support (BTF_KIND_ENUM64) first shipped in Linux 6.0, which
was released on October 2, 2022. So those kernels are old as well.

>
> Dropping the legacy comparison would lose existing negative-enumerator
> name matches for 1-, 2- and 8-byte ENUMs in bpftool, and the 8-byte
> case in libbpf. In the proposed code, 4-byte ENUMs match through the
> helper with or without the legacy comparison.
>
> I'd keep the legacy comparison to preserve those existing name
> matches. Would you prefer to drop it and rely on kflag alone?
>

Yes, we should simplify stuff instead of adding more quirks and
workarounds. I think it's fair to assume kflag is meaningful by now.

> Thanks,
> Hungyu