Received-SPF: pass (google.com: domain of linux-kernel+bounces-20315-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site>
Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64
 native build
From: Xi Ruoyao <xry111@xry111.site>
To: richard clark <richard.xnu.clark@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>, gcc-help@gcc.gnu.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Date: Tue, 09 Jan 2024 11:05:57 +0800
In-Reply-To: <CAJNi4rPj0Wc7ByqrS-GVLUUEnOFPZi8A5nLLCEEJErqAe16EZw@mail.gmail.com>
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>
	 <CAJNi4rPj0Wc7ByqrS-GVLUUEnOFPZi8A5nLLCEEJErqAe16EZw@mail.gmail.com>
Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual;
 keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 
Precedence: bulk
MIME-Version: 1.0

On Tue, 2024-01-09 at 10:55 +0800, richard clark wrote:
> On Mon, Jan 8, 2024 at 6:56=E2=80=AFPM Xi Ruoyao <xry111@xry111.site> wro=
te:
> >=20
> > 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 ar=
e
> > > > implemented in the glibc:
> > > > target-host $ objdump -t /lib/aarch64-linux-gnu/libc.so.6 | grep __=
aarch64_cas4
> > > > 0000000000130950 l=C2=A0=C2=A0=C2=A0=C2=A0 F .text 0000000000000034=
 __aarch64_cas4_relax
> > > > 0000000000130a10 l=C2=A0=C2=A0=C2=A0=C2=A0 F .text 0000000000000034=
 __aarch64_cas4_rel
> > > > 0000000000130990 l=C2=A0=C2=A0=C2=A0=C2=A0 F .text 0000000000000034=
 __aarch64_cas4_acq
> > > > seems the '__sync_val_compare_and_swap' used in the application wil=
l
> > > > 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', t=
he
> > > > cross-compile/build kernel will link to the glibc?
> > >=20
> > > This is due to a difference in default options between the two compil=
ers; the
> > > kernel isn't linked against libc in either case.
> >=20
> > 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.

Because these functions are provided by libgcc.a:

xry111@defiant:~$ objdump -t /usr/lib/gcc/aarch64-unknown-linux-gnu/13.2.0/=
libgcc.a | grep cas
cas_1_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas1_rela=
x
cas_2_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas2_rela=
x
cas_4_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas4_rela=
x
cas_8_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas8_rela=
x
cas_16_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	000000000000003c .hidden __aarch64_cas16_rel=
ax
cas_1_2.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas1_acq
cas_2_2.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas2_acq
cas_4_2.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas4_acq
cas_8_2.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas8_acq
cas_16_2.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	000000000000003c .hidden __aarch64_cas16_acq
cas_1_3.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas1_rel
cas_2_3.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas2_rel
cas_4_3.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas4_rel
cas_8_3.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas8_rel
cas_16_3.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	000000000000003c .hidden __aarch64_cas16_rel
cas_1_4.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas1_acq_=
rel
cas_2_4.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas2_acq_=
rel
cas_4_4.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas4_acq_=
rel
cas_8_4.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas8_acq_=
rel
cas_16_4.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	000000000000003c .hidden __aarch64_cas16_acq=
_rel
cas_1_5.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000038 .hidden __aarch64_cas1_sync
cas_2_5.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000038 .hidden __aarch64_cas2_sync
cas_4_5.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000038 .hidden __aarch64_cas4_sync
cas_8_5.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000038 .hidden __aarch64_cas8_sync
cas_16_5.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000040 .hidden __aarch64_cas16_syn=
c

It seems libc.so.6 just get these functions from libgcc.a (a hidden
global symbol becomes local when you link it into a shared library).=20
But the Linux kernel cannot use neither libc.so nor libgcc.a.  (I know
some non-Linux kernel developers are overusing libgcc.a for kernels, but
IMO this is just wrong and Linux developers also do not do this.  If the
Linux kernel needs a symbol from libgcc the developers just provide
their own implementation.)
--=20
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University