A gcc-15-based bpf toolchain defaults to C23 and fails to compile various
kernel headers due to their use of a custom 'bool' type.
Explicitly using -std=gnu11 works with both clang and bpf-toolchain.

Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
---
 tools/bpf/bpftool/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 9e9a5f006..ca6c1e04b 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -227,7 +227,7 @@ $(OUTPUT)%.bpf.o: skeleton/%.bpf.c $(OUTPUT)vmlinux.h $(LIBBPF_BOOTSTRAP)
 		-I$(or $(OUTPUT),.) \
 		-I$(srctree)/tools/include/uapi/ \
 		-I$(LIBBPF_BOOTSTRAP_INCLUDE) \
-		-g -O2 -Wall -fno-stack-protector \
+		-g -O2 -Wall -fno-stack-protector -std=gnu11 \
 		--target=bpf -c $< -o $@
 	$(Q)$(LLVM_STRIP) -g $@
 
-- 
2.49.0

On 02/05/2025 09:57, Holger Hoffstätte wrote:
> A gcc-15-based bpf toolchain defaults to C23 and fails to compile various
> kernel headers due to their use of a custom 'bool' type.
> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
> 
> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>

Thanks! I tested that it still works with clang.

Acked-by: Quentin Monnet <qmo@kernel.org>

I didn't manage to compile with gcc, though. I tried with gcc 15.1.1 but
option '--target=bpf' is apparently unrecognised by the gcc version on
my setup.

Out of curiosity, how did you build using gcc for the skeleton? Was it
enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re build
probe successfully?

Thanks,
Quentin

On 2025-05-02 11:26, Quentin Monnet wrote:
> On 02/05/2025 09:57, Holger Hoffstätte wrote:
>> A gcc-15-based bpf toolchain defaults to C23 and fails to compile various
>> kernel headers due to their use of a custom 'bool' type.
>> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
>>
>> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
> 
> Thanks! I tested that it still works with clang.
> 
> Acked-by: Quentin Monnet <qmo@kernel.org>

Thanks!

> I didn't manage to compile with gcc, though. I tried with gcc 15.1.1 but
> option '--target=bpf' is apparently unrecognised by the gcc version on
> my setup.
> 
> Out of curiosity, how did you build using gcc for the skeleton? Was it
> enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re build
> probe successfully?

I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
which is just gcc configured & packaged for the bpf target.
Our bpftool package can be built with clang (default) or without, in
which case it depend on the bpf-toolchain. The idea is to gradually
allow bpf/xdp tooling to build/run without requiring clang.

The --target definition is conditional and removed when not using clang:
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94

The bug for building with the new gcc-15 based toolchain where this
patch originated is here: https://bugs.gentoo.org/955156

Hope this helps!

cheers
Holger

On Fri, May 2, 2025 at 2:53 AM Holger Hoffstätte
<holger@applied-asynchrony.com> wrote:
>
> On 2025-05-02 11:26, Quentin Monnet wrote:
> > On 02/05/2025 09:57, Holger Hoffstätte wrote:
> >> A gcc-15-based bpf toolchain defaults to C23 and fails to compile various
> >> kernel headers due to their use of a custom 'bool' type.
> >> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
> >>
> >> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
> >
> > Thanks! I tested that it still works with clang.
> >
> > Acked-by: Quentin Monnet <qmo@kernel.org>
>
> Thanks!
>
> > I didn't manage to compile with gcc, though. I tried with gcc 15.1.1 but
> > option '--target=bpf' is apparently unrecognised by the gcc version on
> > my setup.
> >
> > Out of curiosity, how did you build using gcc for the skeleton? Was it
> > enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re build
> > probe successfully?
>
> I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
> which is just gcc configured & packaged for the bpf target.
> Our bpftool package can be built with clang (default) or without, in
> which case it depend on the bpf-toolchain. The idea is to gradually
> allow bpf/xdp tooling to build/run without requiring clang.
>
> The --target definition is conditional and removed when not using clang:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94
>
> The bug for building with the new gcc-15 based toolchain where this
> patch originated is here: https://bugs.gentoo.org/955156

So you're fixing this build error:

bpf-unknown-none-gcc \
        -I. \
        -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/include/uapi/
\
        -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/src/bootstrap/libbpf/include
\
        -g -O2 -Wall -fno-stack-protector \
         -c skeleton/profiler.bpf.c -o profiler.bpf.o
In file included from skeleton/profiler.bpf.c:3:
./vmlinux.h:5: warning: ignoring '#pragma clang attribute' [-Wunknown-pragmas]
    5 | #pragma clang attribute push
(__attribute__((preserve_access_index)), apply_to = record)
./vmlinux.h:9845:9: error: cannot use keyword 'false' as enumeration constant
 9845 |         false = 0,
      |         ^~~~~
./vmlinux.h:9845:9: note: 'false' is a keyword with '-std=c23' onwards
./vmlinux.h:31137:15: error: 'bool' cannot be defined via 'typedef'
31137 | typedef _Bool bool;
      |               ^~~~

with -std=gnu11 flag and
ignoring an important warning ?

It's a good thing that the build broke.
-std=gnu11 will silence the error, but that warning will still be there
and the generated bpf program will be broken.
End result: partially functional bpftool,
and users will have no idea why some features of bpftool are not working.

pw-bot: cr

On 2025-05-03 04:36, Alexei Starovoitov wrote:
> On Fri, May 2, 2025 at 2:53 AM Holger Hoffstätte
> <holger@applied-asynchrony.com> wrote:
>>
>> On 2025-05-02 11:26, Quentin Monnet wrote:
>>> On 02/05/2025 09:57, Holger Hoffstätte wrote:
>>>> A gcc-15-based bpf toolchain defaults to C23 and fails to compile various
>>>> kernel headers due to their use of a custom 'bool' type.
>>>> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
>>>>
>>>> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
>>>
>>> Thanks! I tested that it still works with clang.
>>>
>>> Acked-by: Quentin Monnet <qmo@kernel.org>
>>
>> Thanks!
>>
>>> I didn't manage to compile with gcc, though. I tried with gcc 15.1.1 but
>>> option '--target=bpf' is apparently unrecognised by the gcc version on
>>> my setup.
>>>
>>> Out of curiosity, how did you build using gcc for the skeleton? Was it
>>> enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re build
>>> probe successfully?
>>
>> I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
>> which is just gcc configured & packaged for the bpf target.
>> Our bpftool package can be built with clang (default) or without, in
>> which case it depend on the bpf-toolchain. The idea is to gradually
>> allow bpf/xdp tooling to build/run without requiring clang.
>>
>> The --target definition is conditional and removed when not using clang:
>> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94
>>
>> The bug for building with the new gcc-15 based toolchain where this
>> patch originated is here: https://bugs.gentoo.org/955156
> 
> So you're fixing this build error:
> 
> bpf-unknown-none-gcc \
>          -I. \
>          -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/include/uapi/
> \
>          -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/src/bootstrap/libbpf/include
> \
>          -g -O2 -Wall -fno-stack-protector \
>           -c skeleton/profiler.bpf.c -o profiler.bpf.o
> In file included from skeleton/profiler.bpf.c:3:
> ./vmlinux.h:5: warning: ignoring '#pragma clang attribute' [-Wunknown-pragmas]
>      5 | #pragma clang attribute push
> (__attribute__((preserve_access_index)), apply_to = record)
> ./vmlinux.h:9845:9: error: cannot use keyword 'false' as enumeration constant
>   9845 |         false = 0,
>        |         ^~~~~
> ./vmlinux.h:9845:9: note: 'false' is a keyword with '-std=c23' onwards
> ./vmlinux.h:31137:15: error: 'bool' cannot be defined via 'typedef'
> 31137 | typedef _Bool bool;
>        |               ^~~~
> 
> with -std=gnu11 flag and

Yes, correct. This is the same as all over the kernel or the bpf tests
for handling C23. I fully understand that this particular patch is only
one piece of the puzzle.

> ignoring an important warning ?

Nobody is (or was) ignoring the warning - it was under discussion when
I posted the patch. After reaching out to Oracle to verify, we have now
added the BPF_NO_PRESERVE_ACCESS_INDEX define when building with gcc-bpf;
this resolves the warning, just like in the bpf self-tests.

You are right that such an addition to the in-kernel bpftool build is
still missing. If you have a suggestion on how best to do that via the
existing Makefile I'm all ears.

As for the remaining warnings - we are also very aware of the ongoing
upstream work to support btf_type_tag:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html.

> End result: partially functional bpftool,
> and users will have no idea why some features of bpftool are not working.

First of all this is never shipped to any users; using gcc-bpf requires
active opt-in by developers or users, and now also warns that such a setup
may result in unexpected bugs due to ongoing work in both Linux and bpftool.
Like I said before, by default everyone builds with clang and that is also
true for our distributed binaries.

If you think adding the -std=gnu11 bit is inappropriate at this time then
just ignore this patch for now. Sooner or later the bpftool build will have
to be adapted with BPF_CFLAGS (liek in the selftests) and hopefuilly an
abstracted BPF_CC so that we no longer have to pretend to be clang when
using gcc.

cheers
Holger

On Sun, May 4, 2025 at 3:24 AM Holger Hoffstätte
<holger@applied-asynchrony.com> wrote:
>
> On 2025-05-03 04:36, Alexei Starovoitov wrote:
> > On Fri, May 2, 2025 at 2:53 AM Holger Hoffstätte
> > <holger@applied-asynchrony.com> wrote:
> >>
> >> On 2025-05-02 11:26, Quentin Monnet wrote:
> >>> On 02/05/2025 09:57, Holger Hoffstätte wrote:
> >>>> A gcc-15-based bpf toolchain defaults to C23 and fails to compile various
> >>>> kernel headers due to their use of a custom 'bool' type.
> >>>> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
> >>>>
> >>>> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
> >>>
> >>> Thanks! I tested that it still works with clang.
> >>>
> >>> Acked-by: Quentin Monnet <qmo@kernel.org>
> >>
> >> Thanks!
> >>
> >>> I didn't manage to compile with gcc, though. I tried with gcc 15.1.1 but
> >>> option '--target=bpf' is apparently unrecognised by the gcc version on
> >>> my setup.
> >>>
> >>> Out of curiosity, how did you build using gcc for the skeleton? Was it
> >>> enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re build
> >>> probe successfully?
> >>
> >> I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
> >> which is just gcc configured & packaged for the bpf target.
> >> Our bpftool package can be built with clang (default) or without, in
> >> which case it depend on the bpf-toolchain. The idea is to gradually
> >> allow bpf/xdp tooling to build/run without requiring clang.
> >>
> >> The --target definition is conditional and removed when not using clang:
> >> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94
> >>
> >> The bug for building with the new gcc-15 based toolchain where this
> >> patch originated is here: https://bugs.gentoo.org/955156
> >
> > So you're fixing this build error:
> >
> > bpf-unknown-none-gcc \
> >          -I. \
> >          -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/include/uapi/
> > \
> >          -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/src/bootstrap/libbpf/include
> > \
> >          -g -O2 -Wall -fno-stack-protector \
> >           -c skeleton/profiler.bpf.c -o profiler.bpf.o
> > In file included from skeleton/profiler.bpf.c:3:
> > ./vmlinux.h:5: warning: ignoring '#pragma clang attribute' [-Wunknown-pragmas]
> >      5 | #pragma clang attribute push
> > (__attribute__((preserve_access_index)), apply_to = record)
> > ./vmlinux.h:9845:9: error: cannot use keyword 'false' as enumeration constant
> >   9845 |         false = 0,
> >        |         ^~~~~
> > ./vmlinux.h:9845:9: note: 'false' is a keyword with '-std=c23' onwards
> > ./vmlinux.h:31137:15: error: 'bool' cannot be defined via 'typedef'
> > 31137 | typedef _Bool bool;
> >        |               ^~~~
> >
> > with -std=gnu11 flag and
>
> Yes, correct. This is the same as all over the kernel or the bpf tests
> for handling C23. I fully understand that this particular patch is only
> one piece of the puzzle.
>

What's the best way to detect (at compile time) whether bool, false,
and true are treated as reserved keywords? To solve this properly
vmlinux.h would have to be adjusted by vmlinux.h to avoid emitting
bool/false/true *iff* compiler version/mode doesn't like that

> > ignoring an important warning ?
>
> Nobody is (or was) ignoring the warning - it was under discussion when
> I posted the patch. After reaching out to Oracle to verify, we have now
> added the BPF_NO_PRESERVE_ACCESS_INDEX define when building with gcc-bpf;
> this resolves the warning, just like in the bpf self-tests.
>
> You are right that such an addition to the in-kernel bpftool build is
> still missing. If you have a suggestion on how best to do that via the
> existing Makefile I'm all ears.
>
> As for the remaining warnings - we are also very aware of the ongoing
> upstream work to support btf_type_tag:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html.
>
> > End result: partially functional bpftool,
> > and users will have no idea why some features of bpftool are not working.
>
> First of all this is never shipped to any users; using gcc-bpf requires
> active opt-in by developers or users, and now also warns that such a setup
> may result in unexpected bugs due to ongoing work in both Linux and bpftool.
> Like I said before, by default everyone builds with clang and that is also
> true for our distributed binaries.
>
> If you think adding the -std=gnu11 bit is inappropriate at this time then
> just ignore this patch for now. Sooner or later the bpftool build will have
> to be adapted with BPF_CFLAGS (liek in the selftests) and hopefuilly an
> abstracted BPF_CC so that we no longer have to pretend to be clang when
> using gcc.
>
> cheers
> Holger

On 2025-05-06 2:04 p.m., Andrii Nakryiko wrote:
 > On Sun, May 4, 2025 at 3:24 AM Holger Hoffstätte
 > <holger@applied-asynchrony.com> wrote:
 >>
 >> On 2025-05-03 04:36, Alexei Starovoitov wrote:
 >>> On Fri, May 2, 2025 at 2:53 AM Holger Hoffstätte
 >>> <holger@applied-asynchrony.com> wrote:
 >>>>
 >>>> On 2025-05-02 11:26, Quentin Monnet wrote:
 >>>>> On 02/05/2025 09:57, Holger Hoffstätte wrote:
 >>>>>> A gcc-15-based bpf toolchain defaults to C23 and fails to 
compile various
 >>>>>> kernel headers due to their use of a custom 'bool' type.
 >>>>>> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
 >>>>>>
 >>>>>> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
 >>>>>
 >>>>> Thanks! I tested that it still works with clang.
 >>>>>
 >>>>> Acked-by: Quentin Monnet <qmo@kernel.org>
 >>>>
 >>>> Thanks!
 >>>>
 >>>>> I didn't manage to compile with gcc, though. I tried with gcc 
15.1.1 but
 >>>>> option '--target=bpf' is apparently unrecognised by the gcc 
version on
 >>>>> my setup.
 >>>>>
 >>>>> Out of curiosity, how did you build using gcc for the skeleton? 
Was it
 >>>>> enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re 
build
 >>>>> probe successfully?
 >>>>
 >>>> I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
 >>>> which is just gcc configured & packaged for the bpf target.
 >>>> Our bpftool package can be built with clang (default) or without, in
 >>>> which case it depend on the bpf-toolchain. The idea is to gradually
 >>>> allow bpf/xdp tooling to build/run without requiring clang.
 >>>>
 >>>> The --target definition is conditional and removed when not using 
clang:
 >>>> 
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94
 >>>>
 >>>> The bug for building with the new gcc-15 based toolchain where this
 >>>> patch originated is here: https://bugs.gentoo.org/955156
 >>>
 >>> So you're fixing this build error:
 >>>
 >>> bpf-unknown-none-gcc \
 >>>           -I. \
 >>> 
-I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/include/uapi/
 >>> \
 >>> 
-I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/src/bootstrap/libbpf/include
 >>> \
 >>>           -g -O2 -Wall -fno-stack-protector \
 >>>            -c skeleton/profiler.bpf.c -o profiler.bpf.o
 >>> In file included from skeleton/profiler.bpf.c:3:
 >>> ./vmlinux.h:5: warning: ignoring '#pragma clang attribute' 
[-Wunknown-pragmas]
 >>>       5 | #pragma clang attribute push
 >>> (__attribute__((preserve_access_index)), apply_to = record)
 >>> ./vmlinux.h:9845:9: error: cannot use keyword 'false' as 
enumeration constant
 >>>    9845 |         false = 0,
 >>>         |         ^~~~~
 >>> ./vmlinux.h:9845:9: note: 'false' is a keyword with '-std=c23' onwards
 >>> ./vmlinux.h:31137:15: error: 'bool' cannot be defined via 'typedef'
 >>> 31137 | typedef _Bool bool;
 >>>         |               ^~~~
 >>>
 >>> with -std=gnu11 flag and
 >>
 >> Yes, correct. This is the same as all over the kernel or the bpf tests
 >> for handling C23. I fully understand that this particular patch is only
 >> one piece of the puzzle.
 >>
 >
 > What's the best way to detect (at compile time) whether bool, false,
 > and true are treated as reserved keywords? To solve this properly
 > vmlinux.h would have to be adjusted by vmlinux.h to avoid emitting
 > bool/false/true *iff* compiler version/mode doesn't like that
I ran into this when adding GCC BPF to CI [1].

One can do something like:

      #if __STDC_VERSION__ < 202311L
      enum {
          false = 0,
          true = 1,
      };
      #endif

But in case of vmlinux.h this would require hacking bpftool, and so for 
selftests/bpf we decided to pass -std=gnu11 [2].

[1] 
https://lore.kernel.org/bpf/CAADnVQKNqdLW1bpvCpVV3yNizwra0cCkBnAbsNp3rTmi8WFcvQ@mail.gmail.com/
[2] 
https://lore.kernel.org/bpf/20250107235813.2964472-1-ihor.solodrai@pm.me/

 >
 >>> ignoring an important warning ?
 >>
 >> Nobody is (or was) ignoring the warning - it was under discussion when
 >> I posted the patch. After reaching out to Oracle to verify, we have now
 >> added the BPF_NO_PRESERVE_ACCESS_INDEX define when building with 
gcc-bpf;
 >> this resolves the warning, just like in the bpf self-tests.
 >>
 >> You are right that such an addition to the in-kernel bpftool build is
 >> still missing. If you have a suggestion on how best to do that via the
 >> existing Makefile I'm all ears.
 >>
 >> As for the remaining warnings - we are also very aware of the ongoing
 >> upstream work to support btf_type_tag:
 >> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html.
 >>
 >>> End result: partially functional bpftool,
 >>> and users will have no idea why some features of bpftool are not 
working.
 >>
 >> First of all this is never shipped to any users; using gcc-bpf requires
 >> active opt-in by developers or users, and now also warns that such a 
setup
 >> may result in unexpected bugs due to ongoing work in both Linux and 
bpftool.
 >> Like I said before, by default everyone builds with clang and that 
is also
 >> true for our distributed binaries.
 >>
 >> If you think adding the -std=gnu11 bit is inappropriate at this time 
then
 >> just ignore this patch for now. Sooner or later the bpftool build 
will have
 >> to be adapted with BPF_CFLAGS (liek in the selftests) and hopefuilly an
 >> abstracted BPF_CC so that we no longer have to pretend to be clang when
 >> using gcc.
 >>
 >> cheers
 >> Holger

On Tue, May 6, 2025 at 2:41 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> On 2025-05-06 2:04 p.m., Andrii Nakryiko wrote:
>  > On Sun, May 4, 2025 at 3:24 AM Holger Hoffstätte
>  > <holger@applied-asynchrony.com> wrote:
>  >>
>  >> On 2025-05-03 04:36, Alexei Starovoitov wrote:
>  >>> On Fri, May 2, 2025 at 2:53 AM Holger Hoffstätte
>  >>> <holger@applied-asynchrony.com> wrote:
>  >>>>
>  >>>> On 2025-05-02 11:26, Quentin Monnet wrote:
>  >>>>> On 02/05/2025 09:57, Holger Hoffstätte wrote:
>  >>>>>> A gcc-15-based bpf toolchain defaults to C23 and fails to
> compile various
>  >>>>>> kernel headers due to their use of a custom 'bool' type.
>  >>>>>> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
>  >>>>>>
>  >>>>>> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
>  >>>>>
>  >>>>> Thanks! I tested that it still works with clang.
>  >>>>>
>  >>>>> Acked-by: Quentin Monnet <qmo@kernel.org>
>  >>>>
>  >>>> Thanks!
>  >>>>
>  >>>>> I didn't manage to compile with gcc, though. I tried with gcc
> 15.1.1 but
>  >>>>> option '--target=bpf' is apparently unrecognised by the gcc
> version on
>  >>>>> my setup.
>  >>>>>
>  >>>>> Out of curiosity, how did you build using gcc for the skeleton?
> Was it
>  >>>>> enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re
> build
>  >>>>> probe successfully?
>  >>>>
>  >>>> I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
>  >>>> which is just gcc configured & packaged for the bpf target.
>  >>>> Our bpftool package can be built with clang (default) or without, in
>  >>>> which case it depend on the bpf-toolchain. The idea is to gradually
>  >>>> allow bpf/xdp tooling to build/run without requiring clang.
>  >>>>
>  >>>> The --target definition is conditional and removed when not using
> clang:
>  >>>>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94
>  >>>>
>  >>>> The bug for building with the new gcc-15 based toolchain where this
>  >>>> patch originated is here: https://bugs.gentoo.org/955156
>  >>>
>  >>> So you're fixing this build error:
>  >>>
>  >>> bpf-unknown-none-gcc \
>  >>>           -I. \
>  >>>
> -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/include/uapi/
>  >>> \
>  >>>
> -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/src/bootstrap/libbpf/include
>  >>> \
>  >>>           -g -O2 -Wall -fno-stack-protector \
>  >>>            -c skeleton/profiler.bpf.c -o profiler.bpf.o
>  >>> In file included from skeleton/profiler.bpf.c:3:
>  >>> ./vmlinux.h:5: warning: ignoring '#pragma clang attribute'
> [-Wunknown-pragmas]
>  >>>       5 | #pragma clang attribute push
>  >>> (__attribute__((preserve_access_index)), apply_to = record)
>  >>> ./vmlinux.h:9845:9: error: cannot use keyword 'false' as
> enumeration constant
>  >>>    9845 |         false = 0,
>  >>>         |         ^~~~~
>  >>> ./vmlinux.h:9845:9: note: 'false' is a keyword with '-std=c23' onwards
>  >>> ./vmlinux.h:31137:15: error: 'bool' cannot be defined via 'typedef'
>  >>> 31137 | typedef _Bool bool;
>  >>>         |               ^~~~
>  >>>
>  >>> with -std=gnu11 flag and
>  >>
>  >> Yes, correct. This is the same as all over the kernel or the bpf tests
>  >> for handling C23. I fully understand that this particular patch is only
>  >> one piece of the puzzle.
>  >>
>  >
>  > What's the best way to detect (at compile time) whether bool, false,
>  > and true are treated as reserved keywords? To solve this properly
>  > vmlinux.h would have to be adjusted by vmlinux.h to avoid emitting
>  > bool/false/true *iff* compiler version/mode doesn't like that
> I ran into this when adding GCC BPF to CI [1].
>
> One can do something like:
>
>       #if __STDC_VERSION__ < 202311L
>       enum {
>           false = 0,
>           true = 1,
>       };
>       #endif
>
> But in case of vmlinux.h this would require hacking bpftool, and so for
> selftests/bpf we decided to pass -std=gnu11 [2].

We can adjust btf_dump_is_blacklisted() to ignore bool typedef
(unconditionally), and we'll need to ignore anon enum with false/true
(which is annoying), and then bpftool will unconditionally add the
above block plus typedef _Bool bool.

Would that work?

>
> [1]
> https://lore.kernel.org/bpf/CAADnVQKNqdLW1bpvCpVV3yNizwra0cCkBnAbsNp3rTmi8WFcvQ@mail.gmail.com/
> [2]
> https://lore.kernel.org/bpf/20250107235813.2964472-1-ihor.solodrai@pm.me/
>
>  >
>  >>> ignoring an important warning ?
>  >>
>  >> Nobody is (or was) ignoring the warning - it was under discussion when
>  >> I posted the patch. After reaching out to Oracle to verify, we have now
>  >> added the BPF_NO_PRESERVE_ACCESS_INDEX define when building with
> gcc-bpf;
>  >> this resolves the warning, just like in the bpf self-tests.
>  >>
>  >> You are right that such an addition to the in-kernel bpftool build is
>  >> still missing. If you have a suggestion on how best to do that via the
>  >> existing Makefile I'm all ears.
>  >>
>  >> As for the remaining warnings - we are also very aware of the ongoing
>  >> upstream work to support btf_type_tag:
>  >> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html.
>  >>
>  >>> End result: partially functional bpftool,
>  >>> and users will have no idea why some features of bpftool are not
> working.
>  >>
>  >> First of all this is never shipped to any users; using gcc-bpf requires
>  >> active opt-in by developers or users, and now also warns that such a
> setup
>  >> may result in unexpected bugs due to ongoing work in both Linux and
> bpftool.
>  >> Like I said before, by default everyone builds with clang and that
> is also
>  >> true for our distributed binaries.
>  >>
>  >> If you think adding the -std=gnu11 bit is inappropriate at this time
> then
>  >> just ignore this patch for now. Sooner or later the bpftool build
> will have
>  >> to be adapted with BPF_CFLAGS (liek in the selftests) and hopefuilly an
>  >> abstracted BPF_CC so that we no longer have to pretend to be clang when
>  >> using gcc.
>  >>
>  >> cheers
>  >> Holger

On 2025-05-06 3:23 p.m., Andrii Nakryiko wrote:
> On Tue, May 6, 2025 at 2:41 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> On 2025-05-06 2:04 p.m., Andrii Nakryiko wrote:
>>   > On Sun, May 4, 2025 at 3:24 AM Holger Hoffstätte
>>   > <holger@applied-asynchrony.com> wrote:
>>   >>
>>   >> On 2025-05-03 04:36, Alexei Starovoitov wrote:
>>   >>> On Fri, May 2, 2025 at 2:53 AM Holger Hoffstätte
>>   >>> <holger@applied-asynchrony.com> wrote:
>>   >>>>
>>   >>>> On 2025-05-02 11:26, Quentin Monnet wrote:
>>   >>>>> On 02/05/2025 09:57, Holger Hoffstätte wrote:
>>   >>>>>> A gcc-15-based bpf toolchain defaults to C23 and fails to
>> compile various
>>   >>>>>> kernel headers due to their use of a custom 'bool' type.
>>   >>>>>> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
>>   >>>>>>
>>   >>>>>> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
>>   >>>>>
>>   >>>>> Thanks! I tested that it still works with clang.
>>   >>>>>
>>   >>>>> Acked-by: Quentin Monnet <qmo@kernel.org>
>>   >>>>
>>   >>>> Thanks!
>>   >>>>
>>   >>>>> I didn't manage to compile with gcc, though. I tried with gcc
>> 15.1.1 but
>>   >>>>> option '--target=bpf' is apparently unrecognised by the gcc
>> version on
>>   >>>>> my setup.
>>   >>>>>
>>   >>>>> Out of curiosity, how did you build using gcc for the skeleton?
>> Was it
>>   >>>>> enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re
>> build
>>   >>>>> probe successfully?
>>   >>>>
>>   >>>> I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
>>   >>>> which is just gcc configured & packaged for the bpf target.
>>   >>>> Our bpftool package can be built with clang (default) or without, in
>>   >>>> which case it depend on the bpf-toolchain. The idea is to gradually
>>   >>>> allow bpf/xdp tooling to build/run without requiring clang.
>>   >>>>
>>   >>>> The --target definition is conditional and removed when not using
>> clang:
>>   >>>>
>> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94
>>   >>>>
>>   >>>> The bug for building with the new gcc-15 based toolchain where this
>>   >>>> patch originated is here: https://bugs.gentoo.org/955156
>>   >>>
>>   >>> So you're fixing this build error:
>>   >>>
>>   >>> bpf-unknown-none-gcc \
>>   >>>           -I. \
>>   >>>
>> -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/include/uapi/
>>   >>> \
>>   >>>
>> -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/src/bootstrap/libbpf/include
>>   >>> \
>>   >>>           -g -O2 -Wall -fno-stack-protector \
>>   >>>            -c skeleton/profiler.bpf.c -o profiler.bpf.o
>>   >>> In file included from skeleton/profiler.bpf.c:3:
>>   >>> ./vmlinux.h:5: warning: ignoring '#pragma clang attribute'
>> [-Wunknown-pragmas]
>>   >>>       5 | #pragma clang attribute push
>>   >>> (__attribute__((preserve_access_index)), apply_to = record)
>>   >>> ./vmlinux.h:9845:9: error: cannot use keyword 'false' as
>> enumeration constant
>>   >>>    9845 |         false = 0,
>>   >>>         |         ^~~~~
>>   >>> ./vmlinux.h:9845:9: note: 'false' is a keyword with '-std=c23' onwards
>>   >>> ./vmlinux.h:31137:15: error: 'bool' cannot be defined via 'typedef'
>>   >>> 31137 | typedef _Bool bool;
>>   >>>         |               ^~~~
>>   >>>
>>   >>> with -std=gnu11 flag and
>>   >>
>>   >> Yes, correct. This is the same as all over the kernel or the bpf tests
>>   >> for handling C23. I fully understand that this particular patch is only
>>   >> one piece of the puzzle.
>>   >>
>>   >
>>   > What's the best way to detect (at compile time) whether bool, false,
>>   > and true are treated as reserved keywords? To solve this properly
>>   > vmlinux.h would have to be adjusted by vmlinux.h to avoid emitting
>>   > bool/false/true *iff* compiler version/mode doesn't like that
>>
>> I ran into this when adding GCC BPF to CI [1].
>>
>> One can do something like:
>>
>>        #if __STDC_VERSION__ < 202311L
>>        enum {
>>            false = 0,
>>            true = 1,
>>        };
>>        #endif
>>
>> But in case of vmlinux.h this would require hacking bpftool, and so for
>> selftests/bpf we decided to pass -std=gnu11 [2].
> 
> We can adjust btf_dump_is_blacklisted() to ignore bool typedef
> (unconditionally), and we'll need to ignore anon enum with false/true
> (which is annoying), and then bpftool will unconditionally add the
> above block plus typedef _Bool bool.
> 
> Would that work?

I think yes, but then the question is why do all this work in bpftool 
instead of passing -std=gnu11 to the compiler? Especially given that 
kernel is built with such flags:

$ grep -r --include="[Mm]akefile" 'std=gnu'

     arch/arm64/kernel/vdso32/Makefile:               -std=gnu11
     arch/loongarch/vdso/Makefile:   -std=gnu11 -O2 -g 
-fno-strict-aliasing -fno-common -fno-builtin \
     arch/s390/Makefile:KBUILD_CFLAGS_DECOMPRESSOR := $(CLANG_FLAGS) 
-m64 -O2 -mpacked-stack -std=gnu11
     arch/s390/purgatory/Makefile:KBUILD_CFLAGS := -std=gnu11 
-fno-strict-aliasing -Wall -Wstrict-prototypes
     arch/x86/Makefile:REALMODE_CFLAGS       := -std=gnu11 -m16 -g -Os 
-DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS \
     arch/x86/boot/compressed/Makefile:KBUILD_CFLAGS += -std=gnu11
     drivers/firmware/efi/libstub/Makefile:cflags-$(CONFIG_X86) 
     += -m$(BITS) -D__KERNEL__ -std=gnu11 \
     tools/build/feature/Makefile:   $(BUILDXX) -std=gnu++11
     tools/build/feature/Makefile:   $(BUILDXX) -std=gnu++17 
                     \
     tools/build/feature/Makefile:   $(BUILDXX) -std=gnu++17 
                     \
     tools/build/feature/Makefile:   $(BUILDXX) -std=gnu++17 
                     \
     tools/lib/api/Makefile:CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 
-U_FORTIFY_SOURCE -fPIC
     tools/lib/bpf/Makefile:override CFLAGS += -std=gnu89
     tools/lib/subcmd/Makefile:CFLAGS := -ggdb3 -Wall -Wextra -std=gnu99 
-fPIC
     tools/lib/symbol/Makefile:CFLAGS += -ggdb3 -Wall -Wextra -std=gnu11 
-U_FORTIFY_SOURCE -fPIC
     tools/net/ynl/generated/Makefile:CFLAGS += -std=gnu11 -O2 -W -Wall 
-Wextra -Wno-unused-parameter -Wshadow \
     tools/net/ynl/lib/Makefile:CFLAGS += -std=gnu11 -O2 -W -Wall 
-Wextra -Wno-unused-parameter -Wshadow
     tools/net/ynl/samples/Makefile:CFLAGS += -std=gnu11 -O2 -W -Wall 
-Wextra -Wno-unused-parameter -Wshadow \
     tools/testing/selftests/arm64/gcs/Makefile:             -std=gnu99 
-I../.. -g \
     tools/testing/selftests/arm64/mte/Makefile:CFLAGS += -std=gnu99 -I. 
-pthread
     tools/testing/selftests/arm64/signal/Makefile:CFLAGS += -std=gnu99 -I.
     tools/testing/selftests/bpf/Makefile:CFLAGS += -g $(OPT_FLAGS) 
-rdynamic -std=gnu11                             \
     tools/testing/selftests/bpf/Makefile:        -std=gnu11 
                                     \
     tools/testing/selftests/bpf/Makefile:CXXFLAGS := $(subst 
-std=gnu11,-std=gnu++11,$(CXXFLAGS))
     tools/testing/selftests/capabilities/Makefile:CFLAGS += -O2 -g 
-std=gnu99 -Wall $(KHDR_INCLUDES)
     tools/testing/selftests/clone3/Makefile:CFLAGS += -g -std=gnu99 
$(KHDR_INCLUDES)
     tools/testing/selftests/riscv/mm/Makefile:CFLAGS += -std=gnu99 -I.
     tools/testing/selftests/sync/Makefile:CFLAGS += -O2 -g -std=gnu89 
-pthread -Wall -Wextra
     tools/testing/selftests/vDSO/Makefile:CFLAGS := -std=gnu99 -O2
     tools/testing/selftests/wireguard/qemu/Makefile:        $(CC) -o $@ 
$(CFLAGS) $(LDFLAGS) -std=gnu11 $<
     tools/testing/selftests/x86/Makefile:CFLAGS := -O2 -g -std=gnu99 
-pthread -Wall $(KHDR_INCLUDES)
     Makefile:                        -O2 -fomit-frame-pointer -std=gnu11
     Makefile:KBUILD_CFLAGS += -std=gnu11

> 
>>
>> [1]
>> https://lore.kernel.org/bpf/CAADnVQKNqdLW1bpvCpVV3yNizwra0cCkBnAbsNp3rTmi8WFcvQ@mail.gmail.com/
>> [2]
>> https://lore.kernel.org/bpf/20250107235813.2964472-1-ihor.solodrai@pm.me/
>>
>>   >
>>   >>> ignoring an important warning ?
>>   >>
>>   >> Nobody is (or was) ignoring the warning - it was under discussion when
>>   >> I posted the patch. After reaching out to Oracle to verify, we have now
>>   >> added the BPF_NO_PRESERVE_ACCESS_INDEX define when building with
>> gcc-bpf;
>>   >> this resolves the warning, just like in the bpf self-tests.
>>   >>
>>   >> You are right that such an addition to the in-kernel bpftool build is
>>   >> still missing. If you have a suggestion on how best to do that via the
>>   >> existing Makefile I'm all ears.
>>   >>
>>   >> As for the remaining warnings - we are also very aware of the ongoing
>>   >> upstream work to support btf_type_tag:
>>   >> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html.
>>   >>
>>   >>> End result: partially functional bpftool,
>>   >>> and users will have no idea why some features of bpftool are not
>> working.
>>   >>
>>   >> First of all this is never shipped to any users; using gcc-bpf requires
>>   >> active opt-in by developers or users, and now also warns that such a
>> setup
>>   >> may result in unexpected bugs due to ongoing work in both Linux and
>> bpftool.
>>   >> Like I said before, by default everyone builds with clang and that
>> is also
>>   >> true for our distributed binaries.
>>   >>
>>   >> If you think adding the -std=gnu11 bit is inappropriate at this time
>> then
>>   >> just ignore this patch for now. Sooner or later the bpftool build
>> will have
>>   >> to be adapted with BPF_CFLAGS (liek in the selftests) and hopefuilly an
>>   >> abstracted BPF_CC so that we no longer have to pretend to be clang when
>>   >> using gcc.
>>   >>
>>   >> cheers
>>   >> Holger

On Tue, May 6, 2025 at 3:34 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> On 2025-05-06 3:23 p.m., Andrii Nakryiko wrote:
> > On Tue, May 6, 2025 at 2:41 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
> >>
> >> On 2025-05-06 2:04 p.m., Andrii Nakryiko wrote:
> >>   > On Sun, May 4, 2025 at 3:24 AM Holger Hoffstätte
> >>   > <holger@applied-asynchrony.com> wrote:
> >>   >>
> >>   >> On 2025-05-03 04:36, Alexei Starovoitov wrote:
> >>   >>> On Fri, May 2, 2025 at 2:53 AM Holger Hoffstätte
> >>   >>> <holger@applied-asynchrony.com> wrote:
> >>   >>>>
> >>   >>>> On 2025-05-02 11:26, Quentin Monnet wrote:
> >>   >>>>> On 02/05/2025 09:57, Holger Hoffstätte wrote:
> >>   >>>>>> A gcc-15-based bpf toolchain defaults to C23 and fails to
> >> compile various
> >>   >>>>>> kernel headers due to their use of a custom 'bool' type.
> >>   >>>>>> Explicitly using -std=gnu11 works with both clang and bpf-toolchain.
> >>   >>>>>>
> >>   >>>>>> Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
> >>   >>>>>
> >>   >>>>> Thanks! I tested that it still works with clang.
> >>   >>>>>
> >>   >>>>> Acked-by: Quentin Monnet <qmo@kernel.org>
> >>   >>>>
> >>   >>>> Thanks!
> >>   >>>>
> >>   >>>>> I didn't manage to compile with gcc, though. I tried with gcc
> >> 15.1.1 but
> >>   >>>>> option '--target=bpf' is apparently unrecognised by the gcc
> >> version on
> >>   >>>>> my setup.
> >>   >>>>>
> >>   >>>>> Out of curiosity, how did you build using gcc for the skeleton?
> >> Was it
> >>   >>>>> enough to run "CLANG=gcc make"? Does it pass the clang-bpf-co-re
> >> build
> >>   >>>>> probe successfully?
> >>   >>>>
> >>   >>>> I'm on Gentoo where we have a gcc-14/15 based "bpf-toolchain" package,
> >>   >>>> which is just gcc configured & packaged for the bpf target.
> >>   >>>> Our bpftool package can be built with clang (default) or without, in
> >>   >>>> which case it depend on the bpf-toolchain. The idea is to gradually
> >>   >>>> allow bpf/xdp tooling to build/run without requiring clang.
> >>   >>>>
> >>   >>>> The --target definition is conditional and removed when not using
> >> clang:
> >>   >>>>
> >> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/bpftool/bpftool-7.5.0.ebuild?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113#n94
> >>   >>>>
> >>   >>>> The bug for building with the new gcc-15 based toolchain where this
> >>   >>>> patch originated is here: https://bugs.gentoo.org/955156
> >>   >>>
> >>   >>> So you're fixing this build error:
> >>   >>>
> >>   >>> bpf-unknown-none-gcc \
> >>   >>>           -I. \
> >>   >>>
> >> -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/include/uapi/
> >>   >>> \
> >>   >>>
> >> -I/var/tmp/portage/dev-util/bpftool-7.5.0/work/bpftool-libbpf-v7.5.0-sources/src/bootstrap/libbpf/include
> >>   >>> \
> >>   >>>           -g -O2 -Wall -fno-stack-protector \
> >>   >>>            -c skeleton/profiler.bpf.c -o profiler.bpf.o
> >>   >>> In file included from skeleton/profiler.bpf.c:3:
> >>   >>> ./vmlinux.h:5: warning: ignoring '#pragma clang attribute'
> >> [-Wunknown-pragmas]
> >>   >>>       5 | #pragma clang attribute push
> >>   >>> (__attribute__((preserve_access_index)), apply_to = record)
> >>   >>> ./vmlinux.h:9845:9: error: cannot use keyword 'false' as
> >> enumeration constant
> >>   >>>    9845 |         false = 0,
> >>   >>>         |         ^~~~~
> >>   >>> ./vmlinux.h:9845:9: note: 'false' is a keyword with '-std=c23' onwards
> >>   >>> ./vmlinux.h:31137:15: error: 'bool' cannot be defined via 'typedef'
> >>   >>> 31137 | typedef _Bool bool;
> >>   >>>         |               ^~~~
> >>   >>>
> >>   >>> with -std=gnu11 flag and
> >>   >>
> >>   >> Yes, correct. This is the same as all over the kernel or the bpf tests
> >>   >> for handling C23. I fully understand that this particular patch is only
> >>   >> one piece of the puzzle.
> >>   >>
> >>   >
> >>   > What's the best way to detect (at compile time) whether bool, false,
> >>   > and true are treated as reserved keywords? To solve this properly
> >>   > vmlinux.h would have to be adjusted by vmlinux.h to avoid emitting
> >>   > bool/false/true *iff* compiler version/mode doesn't like that
> >>
> >> I ran into this when adding GCC BPF to CI [1].
> >>
> >> One can do something like:
> >>
> >>        #if __STDC_VERSION__ < 202311L
> >>        enum {
> >>            false = 0,
> >>            true = 1,
> >>        };
> >>        #endif
> >>
> >> But in case of vmlinux.h this would require hacking bpftool, and so for
> >> selftests/bpf we decided to pass -std=gnu11 [2].
> >
> > We can adjust btf_dump_is_blacklisted() to ignore bool typedef
> > (unconditionally), and we'll need to ignore anon enum with false/true
> > (which is annoying), and then bpftool will unconditionally add the
> > above block plus typedef _Bool bool.
> >
> > Would that work?
>
> I think yes, but then the question is why do all this work in bpftool
> instead of passing -std=gnu11 to the compiler? Especially given that

because -std=gnu11 is a mitigation, not a solution (at least for this
issue). The issue is that vmlinux.h (as it is right now) is not
compatible with C23 standard, which artificially limits what BPF users
can use with their .bpf.c code *just because of vmlinux.h*. Why? We
should find a solution to not depend on -std=gnu11 workarounds.

So this is not about bpftool and BPF selftests specifically, it's
about anyone using vmlinux.h.

> kernel is built with such flags:
>
> $ grep -r --include="[Mm]akefile" 'std=gnu'
>

[...]

> >
> >>
> >> [1]
> >> https://lore.kernel.org/bpf/CAADnVQKNqdLW1bpvCpVV3yNizwra0cCkBnAbsNp3rTmi8WFcvQ@mail.gmail.com/
> >> [2]
> >> https://lore.kernel.org/bpf/20250107235813.2964472-1-ihor.solodrai@pm.me/
> >>
> >>   >
> >>   >>> ignoring an important warning ?
> >>   >>
> >>   >> Nobody is (or was) ignoring the warning - it was under discussion when
> >>   >> I posted the patch. After reaching out to Oracle to verify, we have now
> >>   >> added the BPF_NO_PRESERVE_ACCESS_INDEX define when building with
> >> gcc-bpf;
> >>   >> this resolves the warning, just like in the bpf self-tests.
> >>   >>
> >>   >> You are right that such an addition to the in-kernel bpftool build is
> >>   >> still missing. If you have a suggestion on how best to do that via the
> >>   >> existing Makefile I'm all ears.
> >>   >>
> >>   >> As for the remaining warnings - we are also very aware of the ongoing
> >>   >> upstream work to support btf_type_tag:
> >>   >> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html.
> >>   >>
> >>   >>> End result: partially functional bpftool,
> >>   >>> and users will have no idea why some features of bpftool are not
> >> working.
> >>   >>
> >>   >> First of all this is never shipped to any users; using gcc-bpf requires
> >>   >> active opt-in by developers or users, and now also warns that such a
> >> setup
> >>   >> may result in unexpected bugs due to ongoing work in both Linux and
> >> bpftool.
> >>   >> Like I said before, by default everyone builds with clang and that
> >> is also
> >>   >> true for our distributed binaries.
> >>   >>
> >>   >> If you think adding the -std=gnu11 bit is inappropriate at this time
> >> then
> >>   >> just ignore this patch for now. Sooner or later the bpftool build
> >> will have
> >>   >> to be adapted with BPF_CFLAGS (liek in the selftests) and hopefuilly an
> >>   >> abstracted BPF_CC so that we no longer have to pretend to be clang when
> >>   >> using gcc.
> >>   >>
> >>   >> cheers
> >>   >> Holger
>