Received-SPF: pass (google.com: domain of linux-kernel+bounces-20309-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
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> <CAJNi4rOpzmQAW1Fjst-Em=SQ7q8QsQh0PWhVxUizrOW9JukOgQ@mail.gmail.com>
 <ZZvS8rigFJR8L56c@FVFF77S0Q05N> <fb6c8253fd90e66c036a85954c3299bc2c047473.camel@xry111.site>
In-Reply-To: <fb6c8253fd90e66c036a85954c3299bc2c047473.camel@xry111.site>
From: richard clark <richard.xnu.clark@gmail.com>
Date: Tue, 9 Jan 2024 10:55:50 +0800
Message-ID: <CAJNi4rPj0Wc7ByqrS-GVLUUEnOFPZi8A5nLLCEEJErqAe16EZw@mail.gmail.com>
Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64
 native build
To: Xi Ruoyao <xry111@xry111.site>
Cc: Mark Rutland <mark.rutland@arm.com>, 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

On Mon, Jan 8, 2024 at 6:56=E2=80=AFPM Xi Ruoyao <xry111@xry111.site> wrote=
:
>
> On Mon, 2024-01-08 at 10:51 +0000, Mark Rutland via Gcc-help wrote:
> > > 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 __aa=
rch64_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 compiler=
s; the
> > kernel isn't linked against libc in either case.
>
> And even if it's not the kernel but a normal application, it still
> cannot use these functions from Glibc as the objdump output contains
> "l", meaning these symbols are local symbols and they cannot referred
> somewhere out of the libc.so.6 itself.
Actually you can call those builtin atomic functions in you normal
application without link time error, even execute the output binary in
the target machine in case of cross-compile, only if the linked .so is
in your target environment.
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University