Received-SPF: pass (google.com: domain of linux-kernel+bounces-20421-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
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>
 <CAJNi4rPj0Wc7ByqrS-GVLUUEnOFPZi8A5nLLCEEJErqAe16EZw@mail.gmail.com> <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site>
In-Reply-To: <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site>
From: richard clark <richard.xnu.clark@gmail.com>
Date: Tue, 9 Jan 2024 14:04:57 +0800
Message-ID: <CAJNi4rOU_Mohtam0Zce=tymUy52W_ik4kezNsX-f8on76aX1Rw@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 Tue, Jan 9, 2024 at 11:06=E2=80=AFAM Xi Ruoyao <xry111@xry111.site> wrot=
e:
>
> 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> w=
rote:
> > >
> > > 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 =
__aarch64_cas4
> > > > > 0000000000130950 l     F .text 0000000000000034 __aarch64_cas4_re=
lax
> > > > > 0000000000130a10 l     F .text 0000000000000034 __aarch64_cas4_re=
l
> > > > > 0000000000130990 l     F .text 0000000000000034 __aarch64_cas4_ac=
q
> > > > > seems the '__sync_val_compare_and_swap' used in the application w=
ill
> > > > > 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 comp=
ilers; 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.
>
> 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  0000000000000038 .hidden __aarch64_cas1_s=
ync
> cas_2_5.o:     file format elf64-littleaarch64
> 0000000000000000 g     F .text  0000000000000038 .hidden __aarch64_cas2_s=
ync
> cas_4_5.o:     file format elf64-littleaarch64
[...]
>
> 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).

I think libgcc.a should be built with '-fvisibility=3Dhidden' option and
hidden symbols, then as you said it will become a local sym when
linked with the libc.so.6.

> 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.)
Right, kernel should use its own implementation while not the one from
libc.so...
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University