From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 26D98385801A for ; Mon, 8 Jan 2024 10:56:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 26D98385801A Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 26D98385801A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704711389; cv=none; b=nOK/kti6HakczjY3eW7a/nylvqgQHYu/e6UCBVAQHhv5e0gkAKhFcJuPgC8X4qXrlz3DGRIOs+KB/jkZ6OQNZGXVPJRXM57eEBX1KD14LyLSSTPsiCfBN9ZwNLlCxOiv4oLgUOrI/QNXMHwB9u7WjdbL27G27ai2FPwL1JP5giI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704711389; c=relaxed/simple; bh=Wsw4VxPsaW9bnZCq+PzKzCKdeWEwZLad9rpv9ZWX5iY=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=IJHD89y9kqv8rtC3DVX8DtFxEqAxrmOla2qnYpLMnwzbH8ZU/LmW9b0Yw9Gi0E0vJjJXcDwT+cOSnT7oLnPnL6o3m0GyaHIsnunPoNGWkdRDnfxyU2IQq3yJhz9IucvbsDgvEhX6Bkrz2YB86LmmSXh7mA7kmnJo9LNBnIMDvPo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1704711386; bh=Wsw4VxPsaW9bnZCq+PzKzCKdeWEwZLad9rpv9ZWX5iY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=iS/ylMPrguoVUcbjljHhfQUC5GBHTmGgdq4kek68sCysVen5Z6sUUr+GJgSyw3DhW ckiePu64UYmWpU43czVDpBUfXs447DXfdHh00EGPAAX1qmRHeCg6EIfVnuTvassgVy sGjR3+tAuo1aehRJiNxaeMwEoJY3LyadsS94YiK8= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 58CEC66B4F; Mon, 8 Jan 2024 05:56:25 -0500 (EST) Message-ID: Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64 native build From: Xi Ruoyao To: Mark Rutland , richard clark Cc: gcc-help@gcc.gnu.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Date: Mon, 08 Jan 2024 18:56:23 +0800 In-Reply-To: References: Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.3 MIME-Version: 1.0 X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 __aarc= h64_cas4 > > 0000000000130950 l=C2=A0=C2=A0=C2=A0=C2=A0 F .text 0000000000000034 __a= arch64_cas4_relax > > 0000000000130a10 l=C2=A0=C2=A0=C2=A0=C2=A0 F .text 0000000000000034 __a= arch64_cas4_rel > > 0000000000130990 l=C2=A0=C2=A0=C2=A0=C2=A0 F .text 0000000000000034 __a= arch64_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? >=20 > 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. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University