From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 0789E3858C66 for ; Tue, 9 Jan 2024 06:05:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0789E3858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0789E3858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::42b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704780312; cv=none; b=Xl62W4U0ezzssI5KqK2tOL/S/WbwWbAKydMM0gD3L4+U8kABrvE5OzKyo80Gx5CVIYHeMCP4RAd19E2NQit+DWY7abAcMV9b2Ze+2Z+ltFEnIU9DoxuRixLNRunA4uNTG8GkK1AXW28UadhHiBuVYqfnHK/z6KruZpHskgSc9MQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704780312; c=relaxed/simple; bh=iN5Qj4MZrlqgWuIuYQMUFaTSLm2eksZCjqCYXn/ZD/o=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=pHhCTZZb8Ykb7oYIWioce9MEDpQL2MBgX8sQbE2oTY9lVhkXT/fLTv0XlbZHOrz+1JWT7UWyCRXAa17QrFcYntGTk+/aIj5oqLGSZ0j1pUleINyr5QkC+qi/9aJyPFTHr39BgZ9l0CdGMs2xodwjXzrEKaOpJA2RjBLTsI0evDM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3368b1e056eso2366321f8f.3 for ; Mon, 08 Jan 2024 22:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704780309; x=1705385109; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SgmCi2T8RlV9jzAdMCLfEOSGOV4Nrq6cyyUig0fKmGU=; b=TsGsEQud0TsHLyWWxz7RTwPYMTwLCqm3cuUOH2xDlz+VTTGPlQUqdEBT5AHEbrqSAx yV0c1rTm0/Yqfol/EBVfewFBBcok7LlJgKzTLe0B6lOyRw+cnAoiGYXKlO39jT5CViV8 j6fgsZeXzxvg4zJiVy4hmpXlbzDxp2NnOILda7NR0udHXvL8ykatnLMkgIfZAmZtNgFs 2vAjIolvtUeEqXDkNmYWSruAm0LjbP6cTFBeLbZm5nkIUVWZjDncAMpPdlS8cRkXdesD sobpWJeteBf37B6/zn543214eRLsNdBOEpxCFblPE0qwD/3AcGHAuPqVx+yKGaFWwGDO /hDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704780309; x=1705385109; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SgmCi2T8RlV9jzAdMCLfEOSGOV4Nrq6cyyUig0fKmGU=; b=HED0Jp/Xff/H10UQv56KN6hIPMe9zTEcz30MutNsfR5+MusHLDiyJN+WLBlsRkMLh0 wEa4qfbOi6wFYiZ8l4YhNZZLzk7OkbgV3iBzRQEOFuaASdjFqL/y46PnAKDLXz4iEE/U F6gHWc4ii19UAYgE/r0vyTqJYRo4Z9qfum5GzVkPXdz1yYtJ04c4CskkgQwLzN19zT/D Aa18/8Va93JlbRT72F5afDfgrYtMrNYHn6uAvAy4HHdyib16xJDGVBAk+ScW4A9V/1vz gVfvmBPXZs5/gHeqVVktbCc0ciZfYzaygN8rdWUjZCTsEf6CvUfs5rP3GL2EBJFTUviX JQ6w== X-Gm-Message-State: AOJu0YwE3hQy/BBXxzLxCeL2dYbOJdM1VhMNPoeoyU6zRymoISUBr1AH 1S4C2lHBt3GlWs+b2c9JbJ0ollNLIFCtApFIitw= X-Google-Smtp-Source: AGHT+IH0zpm5vmuRa9n/ACK4SI9H3f7AKZvmJ5TJueJvqZzMHXyKCVNUg9jvuF0o/Bk4ZB7LzAaeCdHb8D+jssrgJVI= X-Received: by 2002:a5d:5f90:0:b0:337:400c:e0b8 with SMTP id dr16-20020a5d5f90000000b00337400ce0b8mr239142wrb.98.1704780308462; Mon, 08 Jan 2024 22:05:08 -0800 (PST) MIME-Version: 1.0 References: <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site> In-Reply-To: <9aef98eed96ed32962ce90499291cb30ad5e3e14.camel@xry111.site> From: richard clark Date: Tue, 9 Jan 2024 14:04:57 +0800 Message-ID: Subject: Re: undefined reference to `__aarch64_cas4_sync' error on arm64 native build To: Xi Ruoyao Cc: Mark Rutland , gcc-help@gcc.gnu.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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 Tue, Jan 9, 2024 at 11:06=E2=80=AFAM Xi Ruoyao wrot= e: > > On Tue, 2024-01-09 at 10:55 +0800, richard clark wrote: > > On Mon, Jan 8, 2024 at 6:56=E2=80=AFPM Xi Ruoyao w= rote: > > > > > > 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_re= lax > > > > > 0000000000130a10 l F .text 0000000000000034 __aarch64_cas4_re= l > > > > > 0000000000130990 l F .text 0000000000000034 __aarch64_cas4_ac= q > > > > > seems the '__sync_val_compare_and_swap' used in the application w= ill > > > > > 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 comp= ilers; 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_s= ync > cas_2_5.o: file format elf64-littleaarch64 > 0000000000000000 g F .text 0000000000000038 .hidden __aarch64_cas2_s= ync > 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=3Dhidden' 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 > School of Aerospace Science and Technology, Xidian University