Date: Tue, 27 Mar 2018 13:15:05 -0400 From: Ed Maste <emaste@freebsd.org> To: Antoine Brodin <antoine@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org> Subject: Re: Heads-up: linker (lld) changes for amd64 coming soon Message-ID: <CAPyFy2ActcryGsok%2BLiYbG6%2BP_jTaE8L%2BqAh4ZpoVYu%2Bip_O1A@mail.gmail.com> In-Reply-To: <CAALwa8kfdg31-Vt=v78ZHV1Us9_%2BN01PC7cwiKFe81720Hguhw@mail.gmail.com> References: <CAPyFy2AjEJjryjgGCHAo107mkOUnFbKmkcMVFWQEKKbTEuu8AA@mail.gmail.com> <CAALwa8kfdg31-Vt=v78ZHV1Us9_%2BN01PC7cwiKFe81720Hguhw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 March 2018 at 02:20, Antoine Brodin <antoine@freebsd.org> wrote: >> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the >> first use being Supervisor Mode Access Prevention (SMAP) on amd64. >> This relies on linker support that is available in the in-tree lld and >> in contemporary binutils ld.bfd from ports, but not in the in-tree >> ld.bfd 2.17.50. > > I have no concerns about 1. OK. My guess is I won't get any other feedback on this one until it makes it into a release. I suspect kib will commit this part later this week or early next week. >> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, >> and thus the linker used for linking ports. I plan to switch this to >> default on. >> > > About 2., I am concerned that changes breaking a large number of > ports are committed without portmgr@ approval. > If WITH_LLD_IS_LD is committed as is on amd64, packages for head > won't be published as it doesn't meet our current criteria for > publication. Fair enough - this was the reason I sent the email. I've now gone through and submitted a PR for for each failure that did not already have one. I've also added LLD_UNSAFE to a few ports where where it was straightforward. In this batch of PRs I noticed four main issues: 1. Ports that pass compiler flags, such as -fPIC, to the linker. lld has more strict command-line parsing and rejects these invalid invocations, while ld.bfd happily creates bogus output (e.g. a shared library with a DT_AUXILIARY entry of "PIC"). PR 221808 has a reasonable discussion of this issue. 2. lld has no built-in search paths (/lib, /usr/lib). Normally the linker is invoked from the compiler driver, which provides default search paths. If lld is invoked directly then library search paths must be specified explicitly with -L/lib -L/usr/lib. 3. Shared library protected visibility symbol preemption. 4. lld does not have a built-in default output target. For the common use of the linker (linking individual .o objects into an executable or shared object) lld infers the target from the first object file. However, when the linker is used to convert an arbitrary binary file into an ELF ojbect (via -r -b binary) lld needs the output target to be specified explicitly with -m. The vast majority of skipped ports in the exp-run come from two failures: lang/ghc (PR226872) and lang/fpc (222172). The PR for lang/ghc reports that the current released version of ghc mentions improved lld support; I hope the port update will solve this issue. I submitted a bug report upstream for lang/fpc about one fpc bug that affected lld, and that issue has now been resolved upstream. We'll need to check again once the port is updated.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2ActcryGsok%2BLiYbG6%2BP_jTaE8L%2BqAh4ZpoVYu%2Bip_O1A>