From nobody Mon Mar 2 15:42:22 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fPjqM6FYcz6SrPX; Mon, 02 Mar 2026 15:42:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fPjqM5fSlz3mCK; Mon, 02 Mar 2026 15:42:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1772466143; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CZa6IP31DbDdzS5SUAG4O3KhrPu9txwPgFr5fCbSi6U=; b=ZQOst4ouC6Jz6lGkRRBKSYEoqbBUiIlezIVKp0i8C2iJUb4hMEavL9IZa8gBCoojkJWZ3L WSzs/5wdW92cjvxIYlAqA6WDiykMRksTTf3GXa/NHirIt1Imtk3m1H8Lz9NWMt84zhO1WQ B/K0C40rr6+ffyt+BDm+Yrvptu6qJUidMepHSpVBJ5vOfInNJdXlozp9i9b/5fR8LqL2Dd c15T9PxASvmmkqCdchlV5tUH79k3YuVMtTaUiOszMyOk04HBns833Uo/gkNo4taeuwTE7p xy1wiKLlz3ARETzCDvQ8kodEoA3818DJSQLgIrf7EZIpoPdoOzvGpRXj1SvTEA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1772466143; a=rsa-sha256; cv=none; b=bRpvLNORyarFjNrPzQzS2MDFSH6KkFfCoFXqNJnMdycMCEKLORX9f6sdbBFgTwPOcF6ZHk zZ91CNIF6cLj8IFLHzOP1t1pISAzLSKm4VnGRIh2Y86CqOas62DYlwFKfoa2RrWRvMy20J TcBhkP9z64MtfpCMXfcDRwEMuUpnl9LwehhhdFQ+Je0BqaHVGF0MaA4ScngYWTv1+vj9GU ntFQPPiNX2O/R2A+dDFfCC39YjE/oUkZpouPaTyUMWes0LQuIUEPtXhU4Ry8Dv9Xnc7ks0 DV7wMjq0u5PBiWbsq7tPWNJZPffxFBNF78kj3ghq5FRQGikJzU89oZkRbVuk6w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1772466143; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CZa6IP31DbDdzS5SUAG4O3KhrPu9txwPgFr5fCbSi6U=; b=HcPjLnKU8KoJzRuJyv+5H2pCmDtWc8LIUOPNAPQuxOCVDUsxq8nyR0vm1rcjDW/yPURbJq FIzaEsxke8VnzG2FarZZEW3cBJTeMxrMFInETIWHmkoLiilsyJ+3u87Gi6eAwspc55D6qr qfnfaj5wAijaBC3/6/oDdvE9lI2y1Yo+2pANJTogvyA4ts+0YNcolJekpw31IT+0aRf6cG f3XhAYfo9+RoFgaoSTt0SJ3G0BBMYe5sUp+qhNtVrYk0BktslLMX+BDq0DaNOl8YJ9Hr3I lcKnRGAvmJZ+DhQyDyfkK7QwiXLynkPtm1p33o0DM7A7XvrtvQ+gxOJ0GShvog== Received: from [IPV6:2601:5c0:4202:5670:937:93a7:f96c:e50a] (unknown [IPv6:2601:5c0:4202:5670:937:93a7:f96c:e50a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4fPjqM3gqfz16Nw; Mon, 02 Mar 2026 15:42:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 2 Mar 2026 10:42:22 -0500 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: ee73475119ff - main - llvm: Link private LLVM libraries against compiler_rt for aarch64 Content-Language: en-US To: Mark Millard , Jessica Clarke Cc: "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" , Andrew Turner References: <698a0b1e.1d294.40e36519@gitrepo.freebsd.org> <23acebb1-f71c-46e6-9eea-3fa44316335d@FreeBSD.org> <720e4cb6-fd13-4686-93d9-ef095ad611c2@yahoo.com> <4514bc7c-49c0-46af-b67a-3e4565a7e8cd@yahoo.com> From: John Baldwin In-Reply-To: <4514bc7c-49c0-46af-b67a-3e4565a7e8cd@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/27/26 17:01, Mark Millard wrote: > On 2/27/26 13:24, John Baldwin wrote: >> On 2/27/26 15:55, Mark Millard wrote: >>> On 2/27/26 09:27, John Baldwin wrote: >>>> On 2/9/26 11:47, John Baldwin wrote: >>>>> On 2/9/26 11:40, Jessica Clarke wrote: >>>>>> On 9 Feb 2026, at 16:28, John Baldwin wrote: >>>>>>> >>>>>>> The branch main has been updated by jhb: >>>>>>> >>>>>>> URL: https://cgit.FreeBSD.org/src/commit/? >>>>>>> id=ee73475119ff7aa98bd11828625d524f6ab87f06 >>>>>>> >>>>>>> commit ee73475119ff7aa98bd11828625d524f6ab87f06 >>>>>>> Author:     John Baldwin >>>>>>> AuthorDate: 2026-02-09 16:26:52 +0000 >>>>>>> Commit:     John Baldwin >>>>>>> CommitDate: 2026-02-09 16:26:52 +0000 >>>>>>> >>>>>>>       llvm: Link private LLVM libraries against compiler_rt for >>>>>>> aarch64 >>>>>>> >>>>>>>       This is required for GCC which uses libcalls for outlined >>>>>>> atomics. >>>>>> >>>>>> This doesn’t seem right, they’re provided by libgcc.a, so why aren’t >>>>>> they being pulled in? libcompiler_rt.a doesn’t even have the symbols. >>>>> >>>>> My guess is that we don't link libraries against libgcc by default, >>>>> only >>>>> binaries (maybe this is a GCC feature/bug vs clang)?  I have another >>>>> review >>>>> open for a couple of google test libraries which similarly fail to >>>>> link. >>>> >>>> So after some more digging (along with Jessica), it seems that GCC only >>>> uses -lgcc_s (and not -lgcc) for C++ (but not C) on both Linux and >>>> FreeBSD. >>>> clang's FreeBSD toolchain driver is supposed to mimic GCC but >>>> doesn't, it >>>> applies the C rules even for C++ linking, so clang is implicitly adding >>>> both -lgcc and -lgcc_s for C++. >>>> >>>> On Linux, libgcc.so is a linker script that includes both the dynamic >>>> library and -lgcc which is how the static libgcc (including outline >>>> atomics >>>> for aarch64) is effectively linked into C++ shared libraries on Linux. >>>> (Note: libgcc.so is a linker script on seemingly all arches on Linux, >>>> not >>>> just aarch64) >>>> >>>> So I think we have a couple of choices here.  I can patch the devel/ >>>> freebsd-gccN >>>> ports to stop passing -shared-libgcc to cc1plus which will cause GCC to >>>> follow >>>> the same rules as clang on FreeBSD (passing -lgcc -as-needed -lgcc_s - >>>> no-as-needed >>>> instead of -lgcc_s), or we could change libgcc.so to be a linker script >>>> to match >>>> Linux (and then eventually fix the FreeBSD driver in clang to only pass >>>> -lgcc_s for C++ linking) (I think Andrew already has a review to make >>>> libgcc.so >>>> a linker script). >>>> >>>> I can see arguments both ways.  Using a linker script seems kind of dumb >>>> given >>>> all the hoops GCC goes to internally to decide whether or not to link >>>> only >>>> shared or static or both.  (Esp given libgcc is in theory part of the >>>> compiler, >>>> so the compiler should know that libgcc_s should depend on libgcc and be >>>> able >>>> to encode that in the default drivers.)  OTOH, the linker script >>>> approach would >>>> mean we would more closely align with Linux.  I think Jess favors >>>> patching GCC. >>>> Does anyone else have any strong opinions? >>>> >>> >>> Is the question limited to devel/freebsd-gcc* ? Or does it span >>> lang/gcc* use as well? >> >> We don't really support building the base system with lang/gcc* >> (it's why devel/freebsd-gcc* exist) as the base system builds require >> various changes like kernel printf support, defaulting to libc++, etc. >> > > > Likely more food for thought than you were originally trying to deal > with for aarch64 contexts. I was not trying to indicate that any > devel/freebsd-gcc* commit vs. lang/gcc* commit would/should be the same > commit. More like . . . > > Are all of the potentially involved linking issues/techniques limited to > that aarch64 system context and the use of devel/freebsd-gcc* ? Or are > there, for example, "uses libcalls for outlined atomics" issues also for > lang/gcc* g++* use, especially when it is told to use -stdlib=libc++ > ( the system libc++ ) instead of using libstdc++ ? Do any issues and > techniques generalize beyond devel/freebsd-gcc* use in any meaningful way? > > Even without committing anything for lang/gcc* , notes might prove > useful later for someone, depending on the answers to the above. In the case of googletest and the LLVM libraries, the undefined symbols for atomics weren't in libc++, so I think you would have the same problem if you used lang/gccX to build googletest or llvm in ports using USE_GCC=yes or the like on aarch64. You also might have the problem on RISC-V for builtins where clang tends to inline operations more often than GCC which tends to invoke libcalls. Note that the GCC behavior is not specific to aarch64. In g++specs.cc it defaults to passing --shared-libgcc to the backend on all platforms that support the option unless an explicit --static-libgcc is specified on the command line to g++. For C, it only passes --shared-gcc by default if an ObjC object file is specified as an input to the linker. -- John Baldwin