Date: Fri, 27 Feb 2026 12:27:44 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Jessica Clarke <jrtc27@freebsd.org> Cc: "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org>, Andrew Turner <andrew@FreeBSD.org> Subject: Re: git: ee73475119ff - main - llvm: Link private LLVM libraries against compiler_rt for aarch64 Message-ID: <23acebb1-f71c-46e6-9eea-3fa44316335d@FreeBSD.org> In-Reply-To: <c9039150-1bb1-4466-9142-9e9ad560c73a@FreeBSD.org> References: <698a0b1e.1d294.40e36519@gitrepo.freebsd.org> <E1734CF0-E6FC-40B8-BAD0-DE2269756E2E@freebsd.org> <c9039150-1bb1-4466-9142-9e9ad560c73a@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
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 <jhb@FreeBSD.org> wrote: >>> >>> The branch main has been updated by jhb: >>> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=ee73475119ff7aa98bd11828625d524f6ab87f06 >>> >>> commit ee73475119ff7aa98bd11828625d524f6ab87f06 >>> Author: John Baldwin <jhb@FreeBSD.org> >>> AuthorDate: 2026-02-09 16:26:52 +0000 >>> Commit: John Baldwin <jhb@FreeBSD.org> >>> 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? -- John Baldwinhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23acebb1-f71c-46e6-9eea-3fa44316335d>