Message-ID: <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site>
Date: Tue, 09 Jan 2024 11:05:57 +0800
From: Xi Ruoyao <xry111@...111.site>
To: richard clark <richard.xnu.clark@...il.com>
Cc: Mark Rutland <mark.rutland@....com>, gcc-help@....gnu.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64
 native build

On Tue, 2024-01-09 at 10:55 +0800, richard clark wrote:
> On Mon, Jan 8, 2024 at 6:56 PM Xi Ruoyao <xry111@...111.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 __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.
> > 
> > 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@...iant:~$ 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_relax
cas_2_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas2_relax
cas_4_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas4_relax
cas_8_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	0000000000000034 .hidden __aarch64_cas8_relax
cas_16_1.o:     file format elf64-littleaarch64
0000000000000000 g     F .text	000000000000003c .hidden __aarch64_cas16_relax
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_sync

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). 
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.)
-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University

Powered by blists - more mailing lists