Date: Fri, 27 Feb 2026 14:01:17 -0800 From: Mark Millard <marklmi@yahoo.com> To: John Baldwin <jhb@FreeBSD.org>, Jessica Clarke <jrtc27@freebsd.org> Cc: "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: <4514bc7c-49c0-46af-b67a-3e4565a7e8cd@yahoo.com> In-Reply-To: <f1e53a2a-5b73-46bc-a664-3e6d387be3a4@FreeBSD.org> References: <698a0b1e.1d294.40e36519@gitrepo.freebsd.org> <E1734CF0-E6FC-40B8-BAD0-DE2269756E2E@freebsd.org> <c9039150-1bb1-4466-9142-9e9ad560c73a@FreeBSD.org> <23acebb1-f71c-46e6-9eea-3fa44316335d@FreeBSD.org> <720e4cb6-fd13-4686-93d9-ef095ad611c2@yahoo.com> <f1e53a2a-5b73-46bc-a664-3e6d387be3a4@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
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 <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? >>> >> >> 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. -- === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4514bc7c-49c0-46af-b67a-3e4565a7e8cd>