Re: [PATCH bpf-next 1/2] libbpf: add option to force-anonymize nested structs for BTF dump

[Eduard Zingerman <eddyz87@gmail.com>]

On Wed, 2025-12-17 at 15:52 -0800, Andrii Nakryiko wrote:
> On Wed, Dec 17, 2025 at 1:27 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > 
> > On Wed, Dec 17, 2025 at 1:02 PM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > > 
> > > On Wed, Dec 17, 2025 at 12:50 PM Alan Maguire <alan.maguire@oracle.com> wrote:
> > > > 
> > > > On 17/12/2025 19:35, Eduard Zingerman wrote:
> > > > > On Wed, 2025-12-17 at 11:34 -0800, Eduard Zingerman wrote:
> > > > > > On Wed, 2025-12-17 at 18:41 +0000, Alan Maguire wrote:
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > So maybe the best we can do here is something like the following at the top
> > > > > > > of vmlinux.h:
> > > > > > > 
> > > > > > > #ifndef BPF_USE_MS_EXTENSIONS
> > > > > > > #if __has_builtin(__builtin_FUNCSIG) || defined(_MSC_EXTENSIONS)
> > > > > > > #define BPF_USE_MS_EXTENSIONS
> > > > > > > #endif
> > > > > > > #endif
> > > > > > > 
> > > > > > > ...and then guard using #ifdef BPF_USE_MS_EXTENSIONS
> > > > > > > 
> > > > > > > That will work on clang and perhaps at some point work on gcc, but also
> > > > > > > gives the user the option to supply a macro to force use in cases where
> > > > > > > there is no detection available.
> > > > > > 
> > > > > > Are we sure we need such flexibility?
> > > > > > Maybe just stick with current implementation and unroll the structures
> > > > > > unconditionally?
> > > > > 
> > > > > I mean, the point of the extension is to make the code smaller.
> > > > > But here we are expanding it instead, so why bother?
> > > > 
> > > > Yeah, I'm happy either way; if we have agreement that we just use the nested anon
> > > > struct without macro complications I'll send an updated patch.
> > > 
> > > There is a little bit of semantic meaning being lost when we inline
> > > the struct, but I guess that can't be helped. Let's just
> > > unconditionally inline then. Still better than having extra emit
> > > option, IMO.
> > 
> > tbh I'm concerned about information loss.
> > 
> > If it's not too hard I would do
> > #ifndef BPF_USE_MS_EXTENSIONS
> > #if __has_builtin(__builtin_FUNCSIG)
> > #define BPF_USE_MS_EXTENSIONS
> > #endif
> > 
> 
> Concert I have with this is that we'd need to hard-code this
> bpftool/vmlinux.h-specific #ifdef/#else/#endif logic (with arbitrary
> and custom BPF_USE_MS_EXTENSIONS define use) for -fms-extension
> handling inside generic libbpf btf_dump API, which is not supposed to
> be vmlinux.h specific.
> 
> Wasn't there a way to basically declare -fms-extensions using #pragma
> inside vmlinux.h itself? If yes, what's the problem with using it? Why
> do we need to work-around anything at all then?

Can't find anything relevant in [1] or [2].
[1] https://clang.llvm.org/docs/LanguageExtensions.html
[2] https://clang.llvm.org/docs/UsersManual.html

Google's LLM doesn't know about such pragmas either.

> > and it will guarantee to work for clang while gcc will have structs inlined.
> > 
> > In one of the clang selftests they have this comment:
> > clang/test/Preprocessor/feature_tests.c:
> > #elif __has_builtin(__builtin_FUNCSIG)
> > #error Clang should not have this without '-fms-extensions'
> > #endif
> > 
> > so this detection is a known approach.