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

[Ed Maste]

Some changes related to the amd64 linker are nearly ready to be
committed (within a week or three), so I'm sending this notice to
request any final comments or concerns before these changes are made.

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.

Right now we use lld as the default bootstrap linker for amd64 in
-CURRENT -- that is, the kernel, and userland libraries and binaries
are linked with lld. To revert to ld.bfd for amd64 the build-time knob
WITHOUT_LLD_BOOTSTRAP=yes can currently be added to src.conf. When the
ifunc changes get committed WITHOUT_LLD_BOOTSTRAP=yes will not work
for amd64 kernels (and will be added to BROKEN_OPTIONS).

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.

Most ports build just fine when lld is the system linker, but a few
encounter trouble: some of the ports rely on options not supported by
lld, rely on specific quirks of ld.bfd's implementation, or have a
buggy linker invocation that is silently ignored by ld.bfd.

The majority of such ports have now been adapted to work with lld or
configured to use ld.bfd as the linker, but there are a small number
of failing ports that do not provide a way to use other than the
default system linker /usr/bin/ld. The outstanding issues can be found
in the ports exp-run for lld as /usr/bin/ld, PR214864.

Please follow up if you have any concerns or comments about these
upcoming changes.

[Antoine Brodin]

Post by Ed Maste
Some changes related to the amd64 linker are nearly ready to be
committed (within a week or three), so I'm sending this notice to
request any final comments or concerns before these changes are made.
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.
Right now we use lld as the default bootstrap linker for amd64 in
-CURRENT -- that is, the kernel, and userland libraries and binaries
are linked with lld. To revert to ld.bfd for amd64 the build-time knob
WITHOUT_LLD_BOOTSTRAP=yes can currently be added to src.conf. When the
ifunc changes get committed WITHOUT_LLD_BOOTSTRAP=yes will not work
for amd64 kernels (and will be added to BROKEN_OPTIONS).
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.
Most ports build just fine when lld is the system linker, but a few
encounter trouble: some of the ports rely on options not supported by
lld, rely on specific quirks of ld.bfd's implementation, or have a
buggy linker invocation that is silently ignored by ld.bfd.
The majority of such ports have now been adapted to work with lld or
configured to use ld.bfd as the linker, but there are a small number
of failing ports that do not provide a way to use other than the
default system linker /usr/bin/ld. The outstanding issues can be found
in the ports exp-run for lld as /usr/bin/ld, PR214864.
Please follow up if you have any concerns or comments about these
upcoming changes.

Hi,

I have no concerns about 1.
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.

Antoine

[Ed Maste]

Post by Antoine Brodin

Post by Ed Maste
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.

Post by Antoine Brodin

Post by Ed Maste
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
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.