All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.