HEADS-UP: Linker issues building amd64 kernels with config & make

[Ed Maste]

As of r333461 the amd64 kernel makes use of ifuncs, and requires
support in the linker. A safety belt added in r333470 enforces this,
and will produce an explicit error if the linker does not support
ifuncs.

lld is the default bootstrap linker for amd64 and has ifunc support.
The typical 'make buildworld' (or kernel-toolchain) followed by 'make
buildkernel' process will use lld and successfully link a working
kernel.

The old-style kernel build (using 'config' followed by a 'make' in the
kernel directory) uses the host linker (/usr/bin/ld). This still
defaults to GNU ld 2.17.50, which does not support ifuncs. This can be
worked around in one of two ways:

1. Install lld as the system linker (/usr/bin/ld), by adding
WITH_LLD_IS_LD to /etc/src.conf and building and install world.
WITH_LLD_IS_LD will become the default on amd64 in the near future -
I'm just waiting on updates to the lang/ghc port and another exp-run.

2. Override LD when you build the kernel:
$ LD=ld.lld make

These tool chain components will undergo additional changes for the next while.

[Julian H. Stacey]

Post by Ed Maste
As of r333461 the amd64 kernel makes use of ifuncs, and requires
support in the linker. A safety belt added in r333470 enforces this,
and will produce an explicit error if the linker does not support
ifuncs.
lld is the default bootstrap linker for amd64 and has ifunc support.
The typical 'make buildworld' (or kernel-toolchain) followed by 'make
buildkernel' process will use lld and successfully link a working
kernel.
The old-style kernel build (using 'config' followed by a 'make' in the
kernel directory) uses the host linker (/usr/bin/ld). This still
defaults to GNU ld 2.17.50, which does not support ifuncs. This can be
1. Install lld as the system linker (/usr/bin/ld), by adding
WITH_LLD_IS_LD to /etc/src.conf and building and install world.
WITH_LLD_IS_LD will become the default on amd64 in the near future -
I'm just waiting on updates to the lang/ghc port and another exp-run.
$ LD=ld.lld make
These tool chain components will undergo additional changes for the next while.

I guess this explains :
Date: Sun, 13 May 2018 20:26:38 +0200
Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
.svn_revision 333575
linking kernel.full
iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

PS Bloat factor > 20: 2M static V 40M dynamic,
(normaly dynamics are smaller, not larger).
cd /usr/bin; ls -l *ld*
-r-xr-xr-x 2 root wheel 1935992 May 13 12:48 ld*
-r-xr-xr-x 1 root wheel 40449288 May 13 12:54 ld.lld*
file ld ld.lld
ld: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
statically linked,
for FreeBSD 12.0 (1200063), FreeBSD-style, stripped
ld.lld: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
dynamically linked, interpreter /libexec/ld-elf.so.1,
for FreeBSD 12.0 (1200063), FreeBSD-style, stripped

Cheers,
Julian

[Ed Maste]

Post by Julian H. Stacey
Date: Sun, 13 May 2018 20:26:38 +0200
Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
.svn_revision 333575
linking kernel.full
iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

No, that's something else; I haven't seen that problem before.

Note that we've been using lld as the default bootstrap linker (i.e.,
the linker used to link the world and kernel via 'make buildworld' and
'make buildkernel') since Jan 10 (r327783).

Post by Julian H. Stacey
PS Bloat factor > 20: 2M static V 40M dynamic,

Keep in mind that the in-tree ld.bfd was released over a decade ago,
and has been obsolete for years now; a dynamically-linked contemporary
ld.bfd 12MB. lld is much faster than any of them (more than 20x
compared to in-tree ld.bfd on some operations) and all of the target
architectures are supported by a single binary.

[Dimitry Andric]

Post by Ed Maste

Post by Julian H. Stacey
Date: Sun, 13 May 2018 20:26:38 +0200
Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
.svn_revision 333575
linking kernel.full
iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

No, that's something else; I haven't seen that problem before.
Note that we've been using lld as the default bootstrap linker (i.e.,
the linker used to link the world and kernel via 'make buildworld' and
'make buildkernel') since Jan 10 (r327783).

Post by Julian H. Stacey
PS Bloat factor > 20: 2M static V 40M dynamic,

Keep in mind that the in-tree ld.bfd was released over a decade ago,
and has been obsolete for years now; a dynamically-linked contemporary
ld.bfd 12MB. lld is much faster than any of them (more than 20x
compared to in-tree ld.bfd on some operations) and all of the target
architectures are supported by a single binary.

Not just that: since lld can do link time optimization (LTO), it also
contains large parts of LLVM, e.g. the backend of the compiler.

We could maybe save some space by putting all the LLVM stuff into a
separate dynamic library, and re-using that from both clang and lld, but
such a dynamic library has its own issues. (Takes a long time and lots
of memory to link, and probably takes quite some time to dynamically
load at runtime too.)

-Dimitry

[Julian H. Stacey]

Date: Mon, 14 May 2018 18:58:25 -0400

Post by Julian H. Stacey
Date: Sun, 13 May 2018 20:26:38 +0200
Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
.svn_revision 333575
linking kernel.full
iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'

No, that's something else; I haven't seen that problem before.

Ah ! Thanks

Note that we've been using lld as the default bootstrap linker (i.e.,
the linker used to link the world and kernel via 'make buildworld' and
'make buildkernel') since Jan 10 (r327783).

Post by Julian H. Stacey
PS Bloat factor > 20: 2M static V 40M dynamic,

Keep in mind that the in-tree ld.bfd was released over a decade ago,
and has been obsolete for years now; a dynamically-linked contemporary
ld.bfd 12MB. lld is much faster than any of them (more than 20x
compared to in-tree ld.bfd on some operations) and all of the target
architectures are supported by a single binary.

OK Thanks.

Cheers,
Julian