On Tue, 2024-01-09 at 10:55 +0800, richard clark wrote:
> On Mon, Jan 8, 2024 at 6:56 PM Xi Ruoyao <xry111@xxxxxxxxxxx> 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@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_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@xxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
