On Tue, Jan 9, 2024 at 11:06 AM Xi Ruoyao <xry111@xxxxxxxxxxx> wrote:
>
> 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 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
[...]
>
> 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=hidden' 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@xxxxxxxxxxx>
> School of Aerospace Science and Technology, Xidian University
