All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Michal Suchanek <msuchanek@suse.de>
Cc: bpf <bpf@vger.kernel.org>,
	"Patrick McCarty" <patrick.mccarty@intel.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@kernel.org>, "Björn Töpel" <bjorn@kernel.org>,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	"Jonathan Lemon" <jonathan.lemon@gmail.com>,
	Networking <netdev@vger.kernel.org>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] libbpf: Fix build with latest gcc/binutils with LTO
Date: Mon, 30 Aug 2021 14:35:28 -0700	[thread overview]
Message-ID: <CAEf4BzbwX792higEDr_O+mqdqkZDoD67GuGvE7gEr1tO=U46Og@mail.gmail.com> (raw)
In-Reply-To: <20210827072539.3399-1-msuchanek@suse.de>

On Fri, Aug 27, 2021 at 12:25 AM Michal Suchanek <msuchanek@suse.de> wrote:
>
> From: Patrick McCarty <patrick.mccarty@intel.com>
>
> After updating to binutils 2.35, the build began to fail with an
> assembler error. A bug was opened on the Red Hat Bugzilla a few days
> later for the same issue.
>
> Work around the problem by using the new `symver` attribute (introduced
> in GCC 10) as needed, instead of the `COMPAT_VERSION` and
> `DEFAULT_VERSION` macros, which expand to assembler directives.
>
> Fixes: https://github.com/libbpf/libbpf/issues/338

This is not a proper tag. We used the following form before:

  [0] Closes: https://github.com/libbpf/libbpf/issues/280

So it's a reference. And then mention in commit message that this was
initiated by the issue on Github ([0]), or something along those
lines.


> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1863059
> Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1188749

These are also not proper Fixes: tags for kernel. It's fine if you
mention that this change fixes those bugs, but maybe use the reference
([1], [2]) style for that?

> Signed-off-by: Patrick McCarty <patrick.mccarty@intel.com>
> Make the change conditional on GCC version

This is not a tag, maybe remove this or make it part of the commit
message properly?

> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> ---
>  tools/lib/bpf/libbpf_internal.h | 23 +++++++++++++++++------
>  tools/lib/bpf/xsk.c             |  4 ++--
>  2 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
> index 016ca7cb4f8a..af0f3fb102c0 100644
> --- a/tools/lib/bpf/libbpf_internal.h
> +++ b/tools/lib/bpf/libbpf_internal.h
> @@ -86,20 +86,31 @@
>         (offsetof(TYPE, FIELD) + sizeof(((TYPE *)0)->FIELD))
>  #endif
>
> +#ifdef __GNUC__
> +# if __GNUC__ >= 10
> +#  define DEFAULT_VERSION(internal_name, api_name, version) \
> +__attribute__((__symver__(#api_name "@@" #version)))
> +#  define COMPAT_VERSION(internal_name, api_name, version) \
> +__attribute__((__symver__(#api_name "@" #version)))
> +# endif
> +#endif
> +
> +#if !defined(COMPAT_VERSION) || !defined(DEFAULT_VERSION)

This seems wrong. If __GNUC__ && __GNUC__ >= 10 we'll define
DEFAULT_VERSION and COMPAT_VERSION as if we are linking in shared
library mode. This will be wrong on new GCC *and* static linking mode.
I think the above declarations should be inside #ifdef SHARED section.

Also, can you please write it out as #if defined(__GNUC__) && __GNUC__
>= 10, instead of doubly nested #if/#ifdef condition?


>  /* Symbol versioning is different between static and shared library.
>   * Properly versioned symbols are needed for shared library, but
>   * only the symbol of the new version is needed for static library.
>   */
> -#ifdef SHARED
> -# define COMPAT_VERSION(internal_name, api_name, version) \
> +# ifdef SHARED
> +#  define COMPAT_VERSION(internal_name, api_name, version) \
>         asm(".symver " #internal_name "," #api_name "@" #version);
> -# define DEFAULT_VERSION(internal_name, api_name, version) \
> +#  define DEFAULT_VERSION(internal_name, api_name, version) \
>         asm(".symver " #internal_name "," #api_name "@@" #version);
> -#else
> -# define COMPAT_VERSION(internal_name, api_name, version)
> -# define DEFAULT_VERSION(internal_name, api_name, version) \
> +# else
> +#  define COMPAT_VERSION(internal_name, api_name, version)
> +#  define DEFAULT_VERSION(internal_name, api_name, version) \
>         extern typeof(internal_name) api_name \
>         __attribute__((alias(#internal_name)));
> +# endif
>  #endif
>
>  extern void libbpf_print(enum libbpf_print_level level,
> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
> index e9b619aa0cdf..a2111696ba91 100644
> --- a/tools/lib/bpf/xsk.c
> +++ b/tools/lib/bpf/xsk.c
> @@ -281,6 +281,7 @@ static int xsk_create_umem_rings(struct xsk_umem *umem, int fd,
>         return err;
>  }
>
> +DEFAULT_VERSION(xsk_umem__create_v0_0_4, xsk_umem__create, LIBBPF_0.0.4)
>  int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area,
>                             __u64 size, struct xsk_ring_prod *fill,
>                             struct xsk_ring_cons *comp,
> @@ -345,6 +346,7 @@ struct xsk_umem_config_v1 {
>         __u32 frame_headroom;
>  };
>
> +COMPAT_VERSION(xsk_umem__create_v0_0_2, xsk_umem__create, LIBBPF_0.0.2)
>  int xsk_umem__create_v0_0_2(struct xsk_umem **umem_ptr, void *umem_area,
>                             __u64 size, struct xsk_ring_prod *fill,
>                             struct xsk_ring_cons *comp,
> @@ -358,8 +360,6 @@ int xsk_umem__create_v0_0_2(struct xsk_umem **umem_ptr, void *umem_area,
>         return xsk_umem__create_v0_0_4(umem_ptr, umem_area, size, fill, comp,
>                                         &config);
>  }
> -COMPAT_VERSION(xsk_umem__create_v0_0_2, xsk_umem__create, LIBBPF_0.0.2)
> -DEFAULT_VERSION(xsk_umem__create_v0_0_4, xsk_umem__create, LIBBPF_0.0.4)
>
>  static enum xsk_prog get_xsk_prog(void)
>  {
> --
> 2.31.1
>

  reply	other threads:[~2021-08-30 21:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27  7:25 [PATCH] libbpf: Fix build with latest gcc/binutils with LTO Michal Suchanek
2021-08-30 21:35 ` Andrii Nakryiko [this message]
2021-08-27  7:28 Michal Suchanek
2021-08-27 10:35 ` Michal Suchánek

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='CAEf4BzbwX792higEDr_O+mqdqkZDoD67GuGvE7gEr1tO=U46Og@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.karlsson@intel.com \
    --cc=msuchanek@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=patrick.mccarty@intel.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /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.