All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: richard clark <richard.xnu.clark@gmail.com>
Cc: gcc-help@gcc.gnu.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64 native build
Date: Mon, 8 Jan 2024 10:51:03 +0000	[thread overview]
Message-ID: <ZZvS8rigFJR8L56c@FVFF77S0Q05N> (raw)
In-Reply-To: <CAJNi4rOpzmQAW1Fjst-Em=SQ7q8QsQh0PWhVxUizrOW9JukOgQ@mail.gmail.com>

On Mon, Jan 08, 2024 at 09:28:56AM +0800, richard clark wrote:
> On Fri, Jan 5, 2024 at 2:18 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Jan 02, 2024 at 04:53:53PM +0800, richard clark wrote:
> > > But don't know why the native aarch64 toolchain doesn't have those
> > > builtin atomic functions...
> >
> > I suspect this is down to your toolchain enabling -moutline-atomics by default;
> > that expands the builtins into calls to out-of-line functions. I suspect your
> > cross-compile toolchain doesn't enable that by default.
> >
> > As above, since nothing should be using the builtins, we don't implement
> > out-of-line versions nor do we override the option.
> >
> AFAIK, the native build for the kernel will not link to the libc.so
> but the userland application does, the builtin atomic primitives are
> implemented in the glibc:
> target-host $ objdump -t /lib/aarch64-linux-gnu/libc.so.6 | grep __aarch64_cas4
> 0000000000130950 l     F .text 0000000000000034 __aarch64_cas4_relax
> 0000000000130a10 l     F .text 0000000000000034 __aarch64_cas4_rel
> 0000000000130990 l     F .text 0000000000000034 __aarch64_cas4_acq
> seems the '__sync_val_compare_and_swap' used in the application will
> be renamed to _aarch64_cas4_{relax, rel, acq}. so the kernel will
> complain it will
> link to an 'undefined reference'. But interesting, why the
> cross-compile kernel will not generate the 'undefined reference', the
> cross-compile/build kernel will link to the glibc?

This is due to a difference in default options between the two compilers; the
kernel isn't linked against libc in either case.

Your native compiler evidently has -moutline-atomics enabled in its default
options. With that enabled, the builtin atomics generate calls to out-of-line
functions which the kernel itself does not provide, and hence those result in a
link-time error.

Your cross-compiler evidently does not have -moutline-atomics enabled in its
default options. Without that enabled, the builtin atomics generate inline
atomic instructions rather than function calls. Since these don't depend on
external functions there's no link-time error.

If you pass 'mno-outline-atomics' to your native compiler, the problem should
disappear.

Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: richard clark <richard.xnu.clark@gmail.com>
Cc: gcc-help@gcc.gnu.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64 native build
Date: Mon, 8 Jan 2024 10:51:03 +0000	[thread overview]
Message-ID: <ZZvS8rigFJR8L56c@FVFF77S0Q05N> (raw)
In-Reply-To: <CAJNi4rOpzmQAW1Fjst-Em=SQ7q8QsQh0PWhVxUizrOW9JukOgQ@mail.gmail.com>

On Mon, Jan 08, 2024 at 09:28:56AM +0800, richard clark wrote:
> On Fri, Jan 5, 2024 at 2:18 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Jan 02, 2024 at 04:53:53PM +0800, richard clark wrote:
> > > But don't know why the native aarch64 toolchain doesn't have those
> > > builtin atomic functions...
> >
> > I suspect this is down to your toolchain enabling -moutline-atomics by default;
> > that expands the builtins into calls to out-of-line functions. I suspect your
> > cross-compile toolchain doesn't enable that by default.
> >
> > As above, since nothing should be using the builtins, we don't implement
> > out-of-line versions nor do we override the option.
> >
> AFAIK, the native build for the kernel will not link to the libc.so
> but the userland application does, the builtin atomic primitives are
> implemented in the glibc:
> target-host $ objdump -t /lib/aarch64-linux-gnu/libc.so.6 | grep __aarch64_cas4
> 0000000000130950 l     F .text 0000000000000034 __aarch64_cas4_relax
> 0000000000130a10 l     F .text 0000000000000034 __aarch64_cas4_rel
> 0000000000130990 l     F .text 0000000000000034 __aarch64_cas4_acq
> seems the '__sync_val_compare_and_swap' used in the application will
> be renamed to _aarch64_cas4_{relax, rel, acq}. so the kernel will
> complain it will
> link to an 'undefined reference'. But interesting, why the
> cross-compile kernel will not generate the 'undefined reference', the
> cross-compile/build kernel will link to the glibc?

This is due to a difference in default options between the two compilers; the
kernel isn't linked against libc in either case.

Your native compiler evidently has -moutline-atomics enabled in its default
options. With that enabled, the builtin atomics generate calls to out-of-line
functions which the kernel itself does not provide, and hence those result in a
link-time error.

Your cross-compiler evidently does not have -moutline-atomics enabled in its
default options. Without that enabled, the builtin atomics generate inline
atomic instructions rather than function calls. Since these don't depend on
external functions there's no link-time error.

If you pass 'mno-outline-atomics' to your native compiler, the problem should
disappear.

Mark.

  reply	other threads:[~2024-01-08 10:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-02  3:29 undefined reference to `__aarch64_cas4_sync' error on arm64 native build richard clark
2024-01-02  3:29 ` richard clark
2024-01-02  8:53 ` richard clark
2024-01-02  8:53   ` richard clark
2024-01-04 18:18   ` Mark Rutland
2024-01-04 18:18     ` Mark Rutland
2024-01-08  1:28     ` richard clark
2024-01-08  1:28       ` richard clark
2024-01-08 10:51       ` Mark Rutland [this message]
2024-01-08 10:51         ` Mark Rutland
2024-01-08 10:56         ` Xi Ruoyao
2024-01-08 10:56           ` Xi Ruoyao
2024-01-09  2:55           ` richard clark
2024-01-09  2:55             ` richard clark
2024-01-09  3:05             ` Xi Ruoyao
2024-01-09  3:05               ` Xi Ruoyao
2024-01-09  6:04               ` richard clark
2024-01-09  6:04                 ` richard clark
2024-01-09  7:48               ` Segher Boessenkool
2024-01-09  7:48                 ` Segher Boessenkool
2024-01-09  8:09                 ` Xi Ruoyao
2024-01-09  8:09                   ` Xi Ruoyao
2024-01-09  8:26                   ` Segher Boessenkool
2024-01-09  8:26                     ` Segher Boessenkool
2024-01-10  5:59                     ` richard clark
2024-01-10  5:59                       ` richard clark
2024-01-10 14:10                       ` Segher Boessenkool
2024-01-10 14:10                         ` Segher Boessenkool
2024-01-11  1:42                         ` richard clark
2024-01-11  1:42                           ` richard clark
2024-01-11 11:26                           ` Mark Rutland
2024-01-11 11:26                             ` Mark Rutland
2024-01-15  9:23                             ` richard clark
2024-01-15  9:23                               ` richard clark
2024-01-09  2:52         ` richard clark
2024-01-09  2:52           ` richard clark

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=ZZvS8rigFJR8L56c@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.xnu.clark@gmail.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.