linux-kernel - Re: undefined reference to `__aarch64_cas4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fb6c8253fd90e66c036a85954c3299bc2c047473.camel@xry111.site>
Date: Mon, 08 Jan 2024 18:56:23 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Mark Rutland <mark.rutland@....com>, richard clark
	 <richard.xnu.clark@...il.com>
Cc: 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 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.

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University