Update on using LLVM's lld linker in the FreeBSD base system

[David Chisnall]

On 2 Aug 2016, at 05:19, Ed Maste <emaste at freebsd.org> wrote:
> 
>>> 6. Request ports exp-runs and issue a call for testing with 3rd party
>>> software. Fix issues found during this process.
>> 
>> Experience suggests this may be the long poll :)
> 
> Indeed, and that's a big part of my motivation for trying to make lld
> more readily available as early as possible, even if we're still
> waiting on some required features.

I believe that all of the base system clang’s for supported branches support -fuse-ld=lld (perhaps 10.0 didn’t?), so if we have an lld candidate in ports then it should be easy for user to test it by doing a pkg ins lld and setting LDFLAGS.  Failing that, the fallback to just replacing /usr/bin/ld with a symlink to /usr/local/bin/ld.lld would probably work for ports testing.

We’re probably going to want a ‘needs bfd / gold instead of lld’ knob for a while.  We might need to patch the gcc versions in ports to accept -fuse-ld=lld[1].

I suspect the longer tail for LTO.  There is a bunch of low-hanging fruit in the FreeBSD tree where LTO would likely be a win (I’d expect most of the statically linked stuff to get smaller, if nothing else).

David

[1] gcc and clang interpret -fuse-ld differently.  In clang, -fuse-ld={foo} means ‘${PATH}/ld.{foo}’ is the linker and you should error out if it doesn’t exist. gcc instead hard codes bfd and gold as the two valid options and rejects anything else.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3698 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20160802/92020086/attachment.bin>