Errors compiling BPF programs from Linux selftests/bpf with GCC
Hello everyone.
I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
originally done by Cupertino Miranda [2].
I encountered issues compiling BPF objects for selftests/bpf with
recent GCC 15 snapshots. An additional test runner binary is supposed
to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
set to a directory with GCC binaries for BPF backend. The runner
binary depends on BPF binaries, which are produced by GCC.
The first issue is compilation errors on vmlinux.h:
In file included from progs/linked_maps1.c:4:
/ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
error: expected identifier before ‘false’
8483 | false = 0,
| ^
A snippet from vmlinux.h:
enum {
false = 0,
true = 1,
};
And:
/ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
error: two or more data types in declaration specifiers
23539 | typedef _Bool bool;
| ^~~~
Full log at [3], and also at [4].
You can easily reproduce the errors with a dummy program:
#include "vmlinux.h"
int main() {
return 0;
}
The vmlinux.h is generated from BTF, produced by pahole v1.28 from
DWARF data contained in the vmlinux binary. The vmlinux binary I used
in these experiments is v6.12 (adc218676eef) compiled with gcc 13.3.0
(default Ubuntu installation).
You can download the specific vmlinux.h I tried using a link below [5].
I bisected recent GCC snapshots and determined that the errors related
to the bool declarations started happening on GCC 15-20241117.
Older versions compile the dummy program without errors, however on
attempt to build the selftests there is a different issue: conflicting
int64 definitions (full log at [6]).
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
from /usr/include/x86_64-linux-gnu/bits/socket.h:29,
from /usr/include/x86_64-linux-gnu/sys/socket.h:33,
from /usr/include/linux/if.h:28,
from /usr/include/linux/icmp.h:23,
from progs/test_cls_redirect_dynptr.c:10:
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: error: conflicting
types for ‘int64_t’; have ‘__int64_t’ {aka ‘long long int’}
27 | typedef __int64_t int64_t;
| ^~~
In file included from progs/test_cls_redirect_dynptr.c:6:
/ci/workspace/bpfgcc.20240922/lib/gcc/bpf-unknown-none/15.0.0/include/stdint.h:43:24:
note: previous declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
43 | typedef __INT64_TYPE__ int64_t;
|^~~
This is on a typical ubuntu:noble system:
$ dpkg -s libc6 | grep Version
Version: 2.39-0ubuntu8.3
I got this with snapshots 15-20241110 and 15-20240922 (the oldest I
tested). This problem may or may not be present in the most recent
versions, I can't tell for sure.
GCC team, please investigate and let me know if you're aware of
workarounds or if there is a specific GCC version that you know is
capable of building BPF programs in selftests/bpf.
If you suspect something might be wrong with the includes for BPF
programs, or GCC snapshot build etc, please also let me know. I mostly
relied on Cupertino scripts when setting that up, and assumed the
selftests/bpf/Makefile is handling BPF_GCC correctly.
Thank you, and happy holidays!
[1] https://github.com/libbpf/ci/pull/164
[2] https://github.com/libbpf/ci/pull/144
[3] https://gist.github.com/theihor/98883c4266b3489cee69e5d5aa532e79
[4] https://github.com/libbpf/ci/actions/runs/12522053128/job/34929897322
[5] https://gist.github.com/theihor/785bb250dd1cce3612e70b5f6d258401
[6] https://gist.github.com/theihor/a8aa7201b30ac6b48df77bb1ea3ec0b2
Interested in contributing & GSOC
Hello, I am interested in compilers and have been trying to understand GCC for some time. I am watching the GRC lectures [0] althought I know they are a bit outdated and the FOSDEM 2024 GCC devroom lectures [1]. I have been trying to understand the build system (what files get created during build time and what depends on what etc.) and have read up a bit on GENERIC and GIMPLE and have played around with the dumps, graphs etc. I plan on maybe implementing a pass using GCC plugins or a dummy GCC frontend to get some idea of how things work. Can you suggest a particular area of the compiler or some project / bugs I could work on and pointers on documentation or previous patches related to it? [0]: https://www.cse.iitb.ac.in/grc/index.php?page=videos [1]: https://archive.fosdem.org/2024/schedule/track/gcc/ Sincerely, Aditya Dutt
Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc wrote:
>
> Hello everyone.
>
> I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
> originally done by Cupertino Miranda [2].
>
> I encountered issues compiling BPF objects for selftests/bpf with
> recent GCC 15 snapshots. An additional test runner binary is supposed
> to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
> set to a directory with GCC binaries for BPF backend. The runner
> binary depends on BPF binaries, which are produced by GCC.
>
> The first issue is compilation errors on vmlinux.h:
>
> In file included from progs/linked_maps1.c:4:
> /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
> error: expected identifier before ‘false’
> 8483 | false = 0,
> | ^
>
> A snippet from vmlinux.h:
>
> enum {
> false = 0,
> true = 1,
> };
>
> And:
>
>
> /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
> error: two or more data types in declaration specifiers
> 23539 | typedef _Bool bool;
> | ^~~~
>
> Full log at [3], and also at [4].
These are simple, the selftests/bpf programs need to compile with
-std=gnu17 or -std=gnu11 since GCC has changed the default to C23
which defines false and bool as keywords now and can't be redeclared
like before.
Thanks,
Andrew Pinski
>
> You can easily reproduce the errors with a dummy program:
>
> #include "vmlinux.h"
>
> int main() {
> return 0;
> }
>
> The vmlinux.h is generated from BTF, produced by pahole v1.28 from
> DWARF data contained in the vmlinux binary. The vmlinux binary I used
> in these experiments is v6.12 (adc218676eef) compiled with gcc 13.3.0
> (default Ubuntu installation).
>
> You can download the specific vmlinux.h I tried using a link below [5].
>
> I bisected recent GCC snapshots and determined that the errors related
> to the bool declarations started happening on GCC 15-20241117.
>
> Older versions compile the dummy program without errors, however on
> attempt to build the selftests there is a different issue: conflicting
> int64 definitions (full log at [6]).
>
> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
> from /usr/include/x86_64-linux-gnu/bits/socket.h:29,
> from /usr/include/x86_64-linux-gnu/sys/socket.h:33,
> from /usr/include/linux/if.h:28,
> from /usr/include/linux/icmp.h:23,
> from progs/test_cls_redirect_dynptr.c:10:
> /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: error:
> conflicting types for ‘int64_t’; have ‘__int64_t’ {aka ‘long long int’}
>27 | typedef __int64_t int64_t;
> | ^~~
> In file included from progs/test_cls_redirect_dynptr.c:6:
>
> /ci/workspace/bpfgcc.20240922/lib/gcc/bpf-unknown-none/15.0.0/include/stdint.h:43:24:
> note: previous declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
>43 | typedef __INT64_TYPE__ int64_t;
> |^~~
>
> This is on a typical ubuntu:noble system:
>
> $ dpkg -s libc6 | grep Version
> Version: 2.39-0ubuntu8.3
>
> I got this with snapshots 15-20241110 and 15-20240922 (the oldest I
> tested). This problem may or may not be present in the most recent
> versions, I can't tell for sure.
>
> GCC team, please investigate and let me know if you're aware of
> workarounds or if there is a specific GCC version that you know is
> capable of building BPF programs in selftests/bpf.
>
> If you suspect something might be wrong with the includes for BPF
> programs, or GCC snapshot build etc, please also let me know. I mostly
> relied on Cupertino scripts when setting that up, and assumed the
> selftests/bpf/Makefile is handling BPF_GCC correctly.
>
> Thank you, and happy holidays!
>
> [1] https://github.com/libbpf/ci/pull/164
> [2] https://github.com/libbpf/ci/pull/144
> [3] https://gist.github.com/theihor/98883c4266b3489cee69e5d5aa532e79
> [4] https://github.com/libbpf/ci/actions/runs/12522053128/job/34929897322
> [5] https://gist.github.com/theihor/785bb250dd1cce3612e70b5f6d258401
> [6] https://gist.github.com/theihor/a8aa7201b30ac6b48df77bb1ea3ec0b2
>
>
Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
On Monday, December 30th, 2024 at 4:42 PM, Alexei Starovoitov
wrote:
>
>
> On Mon, Dec 30, 2024 at 12:59 PM Ihor Solodrai ihor.solod...@pm.me wrote:
>
> > On Monday, December 30th, 2024 at 12:36 PM, Sam James s...@gentoo.org wrote:
> >
> > > Andrew Pinski via Gcc gcc@gcc.gnu.org writes:
> > >
> > > > On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc gcc@gcc.gnu.org
> > > > wrote:
> > > >
> > > > > Hello everyone.
> > > > >
> > > > > I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
> > > > > originally done by Cupertino Miranda [2].
> > > > >
> > > > > I encountered issues compiling BPF objects for selftests/bpf with
> > > > > recent GCC 15 snapshots. An additional test runner binary is supposed
> > > > > to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
> > > > > set to a directory with GCC binaries for BPF backend. The runner
> > > > > binary depends on BPF binaries, which are produced by GCC.
> > > > >
> > > > > The first issue is compilation errors on vmlinux.h:
> > > > >
> > > > > In file included from progs/linked_maps1.c:4:
> > > > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
> > > > > error: expected identifier before ‘false’
> > > > > 8483 | false = 0,
> > > > > | ^
> > > > >
> > > > > A snippet from vmlinux.h:
> > > > >
> > > > > enum {
> > > > > false = 0,
> > > > > true = 1,
> > > > > };
> > > > >
> > > > > And:
> > > > >
> > > > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
> > > > > error: two or more data types in declaration specifiers
> > > > > 23539 | typedef _Bool bool;
> > > > > | ^~~~
> > > > >
> > > > > Full log at [3], and also at [4].
> > > >
> > > > These are simple, the selftests/bpf programs need to compile with
> > > > -std=gnu17 or -std=gnu11 since GCC has changed the default to C23
> > > > which defines false and bool as keywords now and can't be redeclared
> > > > like before.
> > >
> > > Yes, the kernel has various issues like this:
> > > https://lore.kernel.org/linux-kbuild/20241119044724.GA2246422@thelio-3990X/.
> > >
> > > Unfortunately, not all the Makefiles correctly declare that they need
> > > gnu11.
> > >
> > > Clang will hit issues like this too when they change default to gnu23.
> >
> > Andrew, Sam, thank you for a swift response.
> >
> > vmlinux.h is generated code, so for the booleans perhaps it's more
> > appropriate to generate a condition, for example:
> >
> > #if STDC_VERSION < 202311L
> > enum {
> > false = 0,
> > true = 1,
> > };
> > #endif
> >
> > Any drawbacks to this?
>
>
> By special hacking this specific enum in bpftool ?
> Feels like overkill when just adding -std=gnu17 will do.
Yeah. I've tried both the flag and a btf_dump hack today, and the hack
is indeed an overkill, assuming we don't care about generating
C23-compilant vmlinux.h. To conditionalize the declarations both the
enum and typedef _Bool have to be matched, so it's actually two hacks.
Although we do use hacks like this, noticed an interesting example
today [1].
Regardless of how the bool-related error is fixed (with STDC_VERSION
condition or std flag), I get the same int64 errors with GCC
15-20241229 when building selftests/bpf [2].
[1] https://github.com/libbpf/libbpf/blob/master/src/btf_dump.c#L1198-L1201
[2] https://gist.github.com/theihor/7e3341c5a1e1209a744994143abd9e62
>
> > Also if vmlinux was built with GCC C23 then I assume DWARF wouldn't
> > contain the debug info for the enum, hence it wouldn't be present in
> > vmlinux.h.
> >
> > I don't think downgrading the standard for a relatively new backend
> > makes sense, especially in the context of CI testing.
>
>
> I don't see why not. The flag affects the front-end while CI adds
> the test coverage to gcc bpf backend.
Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
On Monday, December 30th, 2024 at 12:36 PM, Sam James wrote:
>
>
> Andrew Pinski via Gcc gcc@gcc.gnu.org writes:
>
> > On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc gcc@gcc.gnu.org
> > wrote:
> >
> > > Hello everyone.
> > >
> > > I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
> > > originally done by Cupertino Miranda [2].
> > >
> > > I encountered issues compiling BPF objects for selftests/bpf with
> > > recent GCC 15 snapshots. An additional test runner binary is supposed
> > > to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
> > > set to a directory with GCC binaries for BPF backend. The runner
> > > binary depends on BPF binaries, which are produced by GCC.
> > >
> > > The first issue is compilation errors on vmlinux.h:
> > >
> > > In file included from progs/linked_maps1.c:4:
> > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
> > > error: expected identifier before ‘false’
> > > 8483 | false = 0,
> > > | ^
> > >
> > > A snippet from vmlinux.h:
> > >
> > > enum {
> > > false = 0,
> > > true = 1,
> > > };
> > >
> > > And:
> > >
> > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
> > > error: two or more data types in declaration specifiers
> > > 23539 | typedef _Bool bool;
> > > | ^~~~
> > >
> > > Full log at [3], and also at [4].
> >
> > These are simple, the selftests/bpf programs need to compile with
> > -std=gnu17 or -std=gnu11 since GCC has changed the default to C23
> > which defines false and bool as keywords now and can't be redeclared
> > like before.
>
>
> Yes, the kernel has various issues like this:
> https://lore.kernel.org/linux-kbuild/20241119044724.GA2246422@thelio-3990X/.
>
> Unfortunately, not all the Makefiles correctly declare that they need
> gnu11.
>
> Clang will hit issues like this too when they change default to gnu23.
Andrew, Sam, thank you for a swift response.
vmlinux.h is generated code, so for the booleans perhaps it's more
appropriate to generate a condition, for example:
#if __STDC_VERSION__ < 202311L
enum {
false = 0,
true = 1,
};
#endif
Any drawbacks to this?
Also if vmlinux was built with GCC C23 then I assume DWARF wouldn't
contain the debug info for the enum, hence it wouldn't be present in
vmlinux.h.
I don't think downgrading the standard for a relatively new backend
makes sense, especially in the context of CI testing.
>
> > [...]
Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
Andrew Pinski via Gcc writes:
> On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc
> wrote:
>>
>> Hello everyone.
>>
>> I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
>> originally done by Cupertino Miranda [2].
>>
>> I encountered issues compiling BPF objects for selftests/bpf with
>> recent GCC 15 snapshots. An additional test runner binary is supposed
>> to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
>> set to a directory with GCC binaries for BPF backend. The runner
>> binary depends on BPF binaries, which are produced by GCC.
>>
>> The first issue is compilation errors on vmlinux.h:
>>
>> In file included from progs/linked_maps1.c:4:
>>
>> /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
>> error: expected identifier before ‘false’
>> 8483 | false = 0,
>> | ^
>>
>> A snippet from vmlinux.h:
>>
>> enum {
>> false = 0,
>> true = 1,
>> };
>>
>> And:
>>
>>
>> /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
>> error: two or more data types in declaration specifiers
>> 23539 | typedef _Bool bool;
>> | ^~~~
>>
>> Full log at [3], and also at [4].
>
>
> These are simple, the selftests/bpf programs need to compile with
> -std=gnu17 or -std=gnu11 since GCC has changed the default to C23
> which defines false and bool as keywords now and can't be redeclared
> like before.
Yes, the kernel has various issues like this:
https://lore.kernel.org/linux-kbuild/20241119044724.GA2246422@thelio-3990X/.
Unfortunately, not all the Makefiles correctly declare that they need
gnu11.
Clang will hit issues like this too when they change default to gnu23.
>
> Thanks,
> Andrew Pinski
>
>>
>> You can easily reproduce the errors with a dummy program:
>>
>> #include "vmlinux.h"
>>
>> int main() {
>> return 0;
>> }
>>
>> The vmlinux.h is generated from BTF, produced by pahole v1.28 from
>> DWARF data contained in the vmlinux binary. The vmlinux binary I used
>> in these experiments is v6.12 (adc218676eef) compiled with gcc 13.3.0
>> (default Ubuntu installation).
>>
>> You can download the specific vmlinux.h I tried using a link below [5].
>>
>> I bisected recent GCC snapshots and determined that the errors related
>> to the bool declarations started happening on GCC 15-20241117.
>>
>> Older versions compile the dummy program without errors, however on
>> attempt to build the selftests there is a different issue: conflicting
>> int64 definitions (full log at [6]).
>>
>> In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155,
>> from /usr/include/x86_64-linux-gnu/bits/socket.h:29,
>> from /usr/include/x86_64-linux-gnu/sys/socket.h:33,
>> from /usr/include/linux/if.h:28,
>> from /usr/include/linux/icmp.h:23,
>> from progs/test_cls_redirect_dynptr.c:10:
>> /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: error:
>> conflicting types for ‘int64_t’; have ‘__int64_t’ {aka ‘long long int’}
>>27 | typedef __int64_t int64_t;
>> | ^~~
>> In file included from progs/test_cls_redirect_dynptr.c:6:
>>
>> /ci/workspace/bpfgcc.20240922/lib/gcc/bpf-unknown-none/15.0.0/include/stdint.h:43:24:
>> note: previous declaration of ‘int64_t’ with type ‘int64_t’ {aka ‘long int’}
>>43 | typedef __INT64_TYPE__ int64_t;
>> |^~~
>>
>> This is on a typical ubuntu:noble system:
>>
>> $ dpkg -s libc6 | grep Version
>> Version: 2.39-0ubuntu8.3
>>
>> I got this with snapshots 15-20241110 and 15-20240922 (the oldest I
>> tested). This problem may or may not be present in the most recent
>> versions, I can't tell for sure.
>>
>> GCC team, please investigate and let me know if you're aware of
>> workarounds or if there is a specific GCC version that you know is
>> capable of building BPF programs in selftests/bpf.
>>
>> If you suspect something might be wrong with the includes for BPF
>> programs, or GCC snapshot build etc, please also let me know. I mostly
>> relied on Cupertino scripts when setting that up, and assumed the
>> selftests/bpf/Makefile is handling BPF_GCC correctly.
>>
>> Thank you, and happy holidays!
>>
>> [1] https://github.com/libbpf/ci/pull/164
>> [2] https://github.com/libbpf/ci/pull/144
>> [3] https://gist.github.com/theihor/98883c4266b3489cee69e5d5aa532e79
>> [4] https://github.com/libbpf/ci/actions/runs/12522053128/job/34929897322
>> [5] https://gist.github.com/theihor/785bb250dd1cce3612e70b5f6d258401
>> [6] https://gist.github.com/theihor/a8aa7201b30ac6b48df77bb1ea3ec0b2
>>
>>
Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
Ihor Solodrai writes:
> On Monday, December 30th, 2024 at 12:36 PM, Sam James wrote:
>
>>
>
>>
>
>> Andrew Pinski via Gcc gcc@gcc.gnu.org writes:
>>
>
>> > On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc gcc@gcc.gnu.org
>> > wrote:
>> >
>
>> > > Hello everyone.
>> > >
>
>> > > I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
>> > > originally done by Cupertino Miranda [2].
>> > >
>
>> > > I encountered issues compiling BPF objects for selftests/bpf with
>> > > recent GCC 15 snapshots. An additional test runner binary is supposed
>> > > to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
>> > > set to a directory with GCC binaries for BPF backend. The runner
>> > > binary depends on BPF binaries, which are produced by GCC.
>> > >
>
>> > > The first issue is compilation errors on vmlinux.h:
>> > >
>
>> > > In file included from progs/linked_maps1.c:4:
>> > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
>> > > error: expected identifier before ‘false’
>> > > 8483 | false = 0,
>> > > | ^
>> > >
>
>> > > A snippet from vmlinux.h:
>> > >
>
>> > > enum {
>> > > false = 0,
>> > > true = 1,
>> > > };
>> > >
>
>> > > And:
>> > >
>
>> > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
>> > > error: two or more data types in declaration specifiers
>> > > 23539 | typedef _Bool bool;
>> > > | ^~~~
>> > >
>
>> > > Full log at [3], and also at [4].
>> >
>
>> > These are simple, the selftests/bpf programs need to compile with
>> > -std=gnu17 or -std=gnu11 since GCC has changed the default to C23
>> > which defines false and bool as keywords now and can't be redeclared
>> > like before.
>>
>
>>
>
>> Yes, the kernel has various issues like this:
>> https://lore.kernel.org/linux-kbuild/20241119044724.GA2246422@thelio-3990X/.
>>
>
>> Unfortunately, not all the Makefiles correctly declare that they need
>> gnu11.
>>
>
>> Clang will hit issues like this too when they change default to gnu23.
>
> Andrew, Sam, thank you for a swift response.
Thank you for working on CI for this!
>
> vmlinux.h is generated code, so for the booleans perhaps it's more
> appropriate to generate a condition, for example:
>
> #if __STDC_VERSION__ < 202311L
> enum {
> false = 0,
> true = 1,
> };
> #endif
>
> Any drawbacks to this?
>
I think this is fine (enough), given the kernel isn't interested in using _Bool
as far as I know.
> Also if vmlinux was built with GCC C23 then I assume DWARF wouldn't
> contain the debug info for the enum, hence it wouldn't be present in
> vmlinux.h.
>
> I don't think downgrading the standard for a relatively new backend
> makes sense, especially in the context of CI testing.
The issue is that the kernel overall isn't yet worried about being built
as C23.
>
>>
>
>> > [...]
Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
On Mon, Dec 30, 2024 at 5:26 PM Ihor Solodrai wrote:
>
> > >
> > > #if STDC_VERSION < 202311L
> > > enum {
> > > false = 0,
> > > true = 1,
> > > };
> > > #endif
> > >
> > > Any drawbacks to this?
> >
> >
> > By special hacking this specific enum in bpftool ?
> > Feels like overkill when just adding -std=gnu17 will do.
>
> Yeah. I've tried both the flag and a btf_dump hack today, and the hack
> is indeed an overkill, assuming we don't care about generating
> C23-compilant vmlinux.h. To conditionalize the declarations both the
> enum and typedef _Bool have to be matched, so it's actually two hacks.
> Although we do use hacks like this, noticed an interesting example
> today [1].
>
> Regardless of how the bool-related error is fixed (with STDC_VERSION
> condition or std flag), I get the same int64 errors with GCC
> 15-20241229 when building selftests/bpf [2].
>
> [1] https://github.com/libbpf/libbpf/blob/master/src/btf_dump.c#L1198-L1201
This is more of a workaround for differences in gcc behavior.
There is no way to cure it with a flag.
While in this case -std will work. So use it.
No need for extra hacks.
There is no objective to produce c23 compliant vmlinux.h at the moment.
> [2] https://gist.github.com/theihor/7e3341c5a1e1209a744994143abd9e62
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h
vs
/ci/workspace/bpfgcc.20241229/lib/gcc/bpf-unknown-none/15.0.0/include/stdint.h
looks like a configuration issue.
We can skip test_cls_redirect*.c for now.
Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
On Mon, Dec 30, 2024 at 12:59 PM Ihor Solodrai wrote:
>
> On Monday, December 30th, 2024 at 12:36 PM, Sam James wrote:
>
> >
> >
> > Andrew Pinski via Gcc gcc@gcc.gnu.org writes:
> >
> > > On Mon, Dec 30, 2024 at 12:11 PM Ihor Solodrai via Gcc gcc@gcc.gnu.org
> > > wrote:
> > >
> > > > Hello everyone.
> > > >
> > > > I picked up the work adding GCC BPF backend to BPF CI pipeline [1],
> > > > originally done by Cupertino Miranda [2].
> > > >
> > > > I encountered issues compiling BPF objects for selftests/bpf with
> > > > recent GCC 15 snapshots. An additional test runner binary is supposed
> > > > to be generated by tools/testing/selftests/bpf/Makefile if BPF_GCC is
> > > > set to a directory with GCC binaries for BPF backend. The runner
> > > > binary depends on BPF binaries, which are produced by GCC.
> > > >
> > > > The first issue is compilation errors on vmlinux.h:
> > > >
> > > > In file included from progs/linked_maps1.c:4:
> > > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:8483:9:
> > > > error: expected identifier before ‘false’
> > > > 8483 | false = 0,
> > > > | ^
> > > >
> > > > A snippet from vmlinux.h:
> > > >
> > > > enum {
> > > > false = 0,
> > > > true = 1,
> > > > };
> > > >
> > > > And:
> > > >
> > > > /ci/workspace/tools/testing/selftests/bpf/tools/include/vmlinux.h:23539:15:
> > > > error: two or more data types in declaration specifiers
> > > > 23539 | typedef _Bool bool;
> > > > | ^~~~
> > > >
> > > > Full log at [3], and also at [4].
> > >
> > > These are simple, the selftests/bpf programs need to compile with
> > > -std=gnu17 or -std=gnu11 since GCC has changed the default to C23
> > > which defines false and bool as keywords now and can't be redeclared
> > > like before.
> >
> >
> > Yes, the kernel has various issues like this:
> > https://lore.kernel.org/linux-kbuild/20241119044724.GA2246422@thelio-3990X/.
> >
> > Unfortunately, not all the Makefiles correctly declare that they need
> > gnu11.
> >
> > Clang will hit issues like this too when they change default to gnu23.
>
> Andrew, Sam, thank you for a swift response.
>
> vmlinux.h is generated code, so for the booleans perhaps it's more
> appropriate to generate a condition, for example:
>
> #if __STDC_VERSION__ < 202311L
> enum {
> false = 0,
> true = 1,
> };
> #endif
>
> Any drawbacks to this?
By special hacking this specific enum in bpftool ?
Feels like overkill when just adding -std=gnu17 will do.
>
> Also if vmlinux was built with GCC C23 then I assume DWARF wouldn't
> contain the debug info for the enum, hence it wouldn't be present in
> vmlinux.h.
>
> I don't think downgrading the standard for a relatively new backend
> makes sense, especially in the context of CI testing.
I don't see why not. The flag affects the front-end while CI adds
the test coverage to gcc bpf backend.
