From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Ihor Solodrai <ihor.solodrai@pm.me>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
Cupertino Miranda <cupertino.miranda@oracle.com>,
David Faust <david.faust@oracle.com>,
Elena Zannoni <elena.zannoni@oracle.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Manu Bretelle <chantra@meta.com>,
Eduard Zingerman <eddyz87@gmail.com>,
Mykola Lysenko <mykolal@meta.com>,
Yonghong Song <yonghong.song@linux.dev>,
bpf <bpf@vger.kernel.org>
Subject: Re: Errors compiling BPF programs from Linux selftests/bpf with GCC
Date: Thu, 02 Jan 2025 10:47:12 +0100 [thread overview]
Message-ID: <87jzbdim3j.fsf@oracle.com> (raw)
In-Reply-To: <ZryncitpWOFICUSCu4HLsMIZ7zOuiH5f4jrgjAh0uiOgKvZzQES09eerwIXNonKEq0U6hdI9pHSCPahUKihTeS8NKlVfkcuiRLotteNbQ9I=@pm.me> (Ihor Solodrai's message of "Mon, 30 Dec 2024 20:08:37 +0000")
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.
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
next prev parent reply other threads:[~2025-01-02 9:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 20:08 Errors compiling BPF programs from Linux selftests/bpf with GCC Ihor Solodrai
2024-12-30 20:24 ` Andrew Pinski
2024-12-30 20:36 ` Sam James
2024-12-30 20:59 ` Ihor Solodrai
2024-12-30 21:08 ` Sam James
2024-12-31 0:42 ` Alexei Starovoitov
2024-12-31 1:26 ` Ihor Solodrai
2024-12-31 4:09 ` Alexei Starovoitov
2025-01-02 9:47 ` Jose E. Marchesi [this message]
2025-01-02 17:35 ` Ihor Solodrai
2025-01-02 18:24 ` Jose E. Marchesi
2025-01-03 0:42 ` Eduard Zingerman
2025-01-03 13:23 ` Jose E. Marchesi
2025-01-02 23:04 ` Eduard Zingerman
2025-01-03 0:16 ` Jose E. Marchesi
2025-01-03 0:46 ` Eduard Zingerman
2025-01-03 10:17 ` Jose E. Marchesi
2025-01-03 12:52 ` Jose E. Marchesi
2025-01-03 23:48 ` Ihor Solodrai
2025-01-03 23:56 ` Andrew Pinski
2025-01-04 8:05 ` Jose E. Marchesi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jzbdim3j.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=chantra@meta.com \
--cc=cupertino.miranda@oracle.com \
--cc=david.faust@oracle.com \
--cc=eddyz87@gmail.com \
--cc=elena.zannoni@oracle.com \
--cc=gcc@gcc.gnu.org \
--cc=ihor.solodrai@pm.me \
--cc=mykolal@meta.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.