Re: Heads-up: linker (lld) changes for amd64 coming soon

On 27 March 2018 at 02:20, Antoine Brodin <antoine_at_freebsd.org> wrote:
>> 1. Kostik (kib_at_) 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_at_ 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.