On Thursday, January 2nd, 2025 at 1:47 AM, Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> wrote: > Hi Ihor. > Thanks for working on this! :) > > > [...] > > 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; > > | ^~~~~~~ > > > I think this is what is going on: > > The BPF selftest is indirectly including glibc headers from the host > where it is being compiled. In this case your x86_64 ubuntu system. > > Many glibc headers include bits/wordsize.h, which in the case of x86_64 > is: > > #if defined x86_64 && !defined ILP32 > # define __WORDSIZE 64 > #else > # define __WORDSIZE 32 > #define __WORDSIZE32_SIZE_ULONG 0 > #define __WORDSIZE32_PTRDIFF_LONG 0 > #endif > > and then in bits/types.h: > > #if __WORDSIZE == 64 > typedef signed long int __int64_t; > typedef unsigned long int __uint64_t; > #else > extension typedef signed long long int __int64_t; > extension typedef unsigned long long int __uint64_t; > #endif > > i.e. your BPF program ends using __WORDSIZE 32. This eventually leads > to int64_t being defined as `signed long long int' in stdint-intn.h, as > it would correspond to a x86_64 program running in 32-bit mode. > > GCC BPF, on the other hand, is a "baremetal" compiler and it provides a > small set of headers (including stdint.h) that implement standard C99 > types like int64_t, adjusted to the BPF architecture. > > In this case there is a conflict between the 32-bit x86_64 definition of > int64_t and the one of BPF. Hi Jose, thanks for breaking this down. I was able to mitigate int64_t declaration conflict by passing -nostdinc to gcc. Currently system-installed headers are being passed via -idirafter in a compilation command: /ci/workspace/bpfgcc.20241229/bin/bpf-unknown-none-gcc \ -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian \ -I/ci/workspace/tools/testing/selftests/bpf/tools/include -I/ci/workspace/tools/testing/selftests/bpf \ -I/ci/workspace/tools/include/uapi \ -I/ci/workspace/tools/testing/selftests/usr/include \ -Wno-compare-distinct-pointer-types \ -idirafter /usr/lib/gcc/x86_64-linux-gnu/13/include \ -idirafter /usr/local/include \ -idirafter /usr/include/x86_64-linux-gnu \ -idirafter /usr/include \ -DBPF_NO_PRESERVE_ACCESS_INDEX \ -Wno-attributes \ -O2 -std=gnu17 \ # -nostdinc here helps -c progs/test_cls_redirect.c \ -o /ci/workspace/tools/testing/selftests/bpf/bpf_gcc/test_cls_redirect.bpf.o Passing -nostdinc makes gcc to pick compiler-installed header, if I understand correctly. > > PS: the other headers installed by GCC BPF are: > float.h iso646.h limits.h stdalign.h stdarg.h stdatomic.h stdbool.h > stdckdint.h stddef.h stdfix.h stdint.h stdnoreturn.h syslimits.h > tgmath.h unwind.h varargs.h