[llvm-dev] Linking FreeBSD with lld: update on CPU architecture support

[Ed Maste via llvm-dev]

lld now implements almost all of the functionality necessary to function as
a system linker for FreeBSD/amd64, and I've started investigating other CPU
architectures that FreeBSD supports. Of course some of these are known to
have limited support in lld, but I want to capture a snapshot of where
things stand today.

sparc64 and riscv are excluded as they have no lld support. sparc64 is not
of much interest in FreeBSD any longer (we support only long-obsolete
CPUs), but we have a strong interest in linking FreeBSD/riscv with lld.

PRs or patches will follow after individual issues are diagnosed.

Per-arch status:

## amd64 (aka x86-64)
With WIP patches to both lld and FreeBSD it is possible to link a working
base system kernel and userland.

The primary lld limitation relates to wildcards in extern "C++" blocks in
version scripts. We also need to rework the way the FreeBSD boot components
are built.

Known issues have PRs or patches in review. I hope that we'll soon start
extensively testing the ports collection (the 25K third party software
packages) using lld as the linker.

I posted an update, with a proposed set of steps for importing lld into
FreeBSD, at
https://lists.freebsd.org/pipermail/freebsd-toolchain/2016-August/002240.html
.

## arm
Fails very early on in the build, while linking the target libc.so.7.

relocation R_ARM_REL32 cannot refer to absolute symbol _GLOBAL_OFFSET_TABLE_
can't create dynamic relocation R_ARM_GOTOFF32 against symbol
_libc_arm_fpu_present
can't create dynamic relocation R_ARM_NONE against symbol
__aeabi_unwind_cpp_pr0
...

## arm64
Userland link completes with the same set of WIP patches as above. Minimal
testing has been done on the resulting binaries. The kernel link fails with
thousands of "relocation R_AARCH64_ADR_PREL_PG_HI21 out of range" errors.

## i386
The userland link completes, along with the kernel itself; results
untested. Kernel modules fail with:

can't create dynamic relocation R_386_32 against readonly segment

can't create dynamic relocation R_386_PC32 against symbol device_get_parent

...

## mips64
mips64 uses libstdc++ (not libc++) and the lack of version script wildcard
support for symbols in extern "C++" blocks prevent building it with lld.
Tracked in pr29093. After disabling C++ support much of the userland does
link, but is untested.

Three base system binaries (and related variants of them) fail to build:
gcc, gdb, and svn. The error is "relocation R_MIPS_GOT_DISP out of range".
It's not too surprising as these binaries are expected to be among the
larger ones in the base system, although they do successfully link with GNU
ld. The kernel link fails wtih "duplicate symbol: _gp in (internal) and
(internal)".

## mips
C++ is disabled as described above for mips64. One userland component
(ubldr) failed to build due to a linker script error, to be investigated.
The kernel link fails with "duplicate symbol: _gp in (internal) and
(internal)".

## powerpc (32-bit)
Fails early, linking the target libc.so.7.

can't create dynamic relocation R_PPC_GOT16 against symbol .LANCHOR0
can't create dynamic relocation R_PPC_GOT16 against symbol __cxa_finalize
can't create dynamic relocation R_PPC_GOT16 against symbol __dso_handle
can't create dynamic relocation R_PPC_PLTREL24 against symbol __cxa_finalize
...

% sed -E -n "s/can't create dynamic relocation ([^ ]*).*$/\1/p" build.log |
sort | uniq -c | sort -rn
17658 R_PPC_PLTREL24
9647 R_PPC_GOT16
3274 R_PPC_REL32
 231 R_PPC_GOT_TLSGD16
 101 R_PPC_LOCAL24PC

## powerpc64 (64-bit)
Fails early, linking the target libc.so.7.

can't create dynamic relocation R_PPC64_REL24 against readonly segment
can't create dynamic relocation R_PPC64_REL24 against readonly segment
can't create dynamic relocation R_PPC64_REL24 against symbol _collate_wxfrm

can't create dynamic relocation R_PPC64_REL24 against symbol __get_locale

can't create dynamic relocation R_PPC64_REL24 against symbol __get_locale

...

% sed -E -n "s/can't create dynamic relocation ([^ ]*).*$/\1/p" build.log |
sort | uniq -c | sort -rn
6899 R_PPC64_REL24
2902 R_PPC64_REL32
  27 R_PPC64_REL64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160823/b045d0cf/attachment.html>