Received-SPF: pass (google.com: domain of linux-kernel+bounces-19039-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <CAJNi4rO+Dw5qYDtyJVbuo0OqAoXpGq_Qq6xjH9cvMCAUnW+77g@mail.gmail.com>
 <CAJNi4rMHtM=39jzkzwqt++kVpSp0=XfDrVdY94WoW6B34oKwDA@mail.gmail.com> <ZZb2f0U4qTWDjCGj@FVFF77S0Q05N.cambridge.arm.com>
In-Reply-To: <ZZb2f0U4qTWDjCGj@FVFF77S0Q05N.cambridge.arm.com>
From: richard clark <richard.xnu.clark@gmail.com>
Date: Mon, 8 Jan 2024 09:28:56 +0800
Message-ID: <CAJNi4rOpzmQAW1Fjst-Em=SQ7q8QsQh0PWhVxUizrOW9JukOgQ@mail.gmail.com>
Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64
 native build
To: Mark Rutland <mark.rutland@arm.com>
Cc: gcc-help@gcc.gnu.org, linux-kernel@vger.kernel.org, 
	linux-arm-kernel@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mark,

On Fri, Jan 5, 2024 at 2:18=E2=80=AFAM Mark Rutland <mark.rutland@arm.com> =
wrote:
>
> On Tue, Jan 02, 2024 at 04:53:53PM +0800, richard clark wrote:
> > Ah, the driver is trying to use the native gcc built atomic ops like:
> > __sync_val_compare_and_swap, but it seems the native aarch64 doesn't
> > provide these builtin atomic primitives while they are in the cross
> > compile toolchain.
> > The issue can be resolved by replacing the
> > **__sync_val_compare_and_swap** with **atomic_cmpxchg**.
>
> Yup, that's the right thing to do; drivers *shouldn't* use the builtins
> directly, and *should* use the kernel's native atomic*() API.
>
Right, that's the way I did to fix that.
>
> > 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 de=
fault;
> 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?


>
> Mark.
>
> > On Tue, Jan 2, 2024 at 11:29=E2=80=AFAM richard clark
> > <richard.xnu.clark@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I have a strong power arm64 box, and the linux distro is ubuntu 22.04=
,
> > > the native gcc version is:
> > >
> > > $ gcc --version
> > > gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
> > > Copyright (C) 2021 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions.  There =
is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PU=
RPOSE.
> > >
> > > It will abort the kernel build with the complaint by 'make Image':
> > > ld: Unexpected GOT/PLT entries detected!
> > > ld: Unexpected run-time procedure linkages detected!
> > > ld: ID map text too big or misaligned
> > > ld: drivers/net/nvidia_eth.o: in function `osi_lock_irq_enabled':
> > > osi_hal.c:(.text+0x3cc): undefined reference to `__aarch64_cas4_sync'
> > > ...
> > >
> > > But the cross-compile with aarch64-linux-gnu-gcc on the x86 box
> > > doesn't show the above error message.
> > > Any comments/suggestions? Thanks very much!
> > >
> > > Richard
> >