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 13:27 -0800, Alexei Starovoitov 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
>
> 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.

Speaking of information loss.
It appears that clang does the same trick internally:

  $ cat ms-ext-test2.c
  struct foo {
    int a;
  } __attribute__((preserve_access_index));
  
  struct bar {
    struct foo;
  } __attribute__((preserve_access_index));
  
  int buz(struct bar *bar) {
    return bar->a;
  }

  $ clang -O2 -g -fms-extensions --target=bpf -c ms-ext-test2.c
  ms-ext-test2.c:6:3: warning: anonymous structs are a Microsoft extension [-Wmicrosoft-anon-tag]
      6 |   struct foo;
        |   ^~~~~~~~~~
  1 warning generated.

  $ llvm-objdump -Sdr ms-ext-test2.o
  
  ms-ext-test2.o: file format elf64-bpf
  
  Disassembly of section .text:
  
  0000000000000000 <buz>:
  ;   return bar->a;
         0:       61 10 00 00 00 00 00 00 w0 = *(u32 *)(r1 + 0x0)
                  0000000000000000:  CO-RE <byte_off> [2] struct bar::<anon 0>.a (0:0:0)
         1:       95 00 00 00 00 00 00 00 exit

Note the "<anon 0>" in the relocation.
It appears that we loose no information if structures are unrolled.