Date: Mon, 1 Aug 2016 17:40:07 -0400 From: Ed Maste <emaste@freebsd.org> To: "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org> Subject: Update on using LLVM's lld linker in the FreeBSD base system Message-ID: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Over the past year or so I have been investigating the state of LLVM's lld linker for use in the FreeBSD base system, to see if it could be used as FreeBSD's system linker. Why do we need a new linker? Compared to the GNU ld 2.17.50 that we have in the FreeBSD base system, lld will bring: * AArch64 (arm64) support * Link Time Optimization (LTO) * New ABI support * Other linker optimization * Much faster link times * Maintained code base I've posted a couple of status updates on the LLVM mailing list: http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html Since the last update in March several lld developers have implemented much of the missing functionality. The main blockers were symbol version support and expression evaluation in the linker script expression parser. Both are now nearly complete. There are a few features used by the FreeBSD base system that lld developers (intentionally) do not expect to implement, unless they're reasonably widely used in a variety of different software. If they're not implemented we can modify FreeBSD to avoid using them. I'm aware of: -N/--omagic, used by some boot loader components. We can achieve the same effect with a linker script. -dc, used by the rescue build. As long as object files are built specifically for rescue we can probably use -fno-common instead. -r binary to convert binary files into ELF objects, used by some device drivers in kernel and module builds. We can use objcopy(elfcopy) instead. Davide Italiano and Rafael =C3=81vila de Esp=C3=ADndola presented an update= on the state of lld at BSDCan 2016: https://www.bsdcan.org/2016/schedule/events/656.en.html At this point I'm confident that lld is going to be a viable linker for the FreeBSD base system, and am beginning to plan its import. I expect the process will look something like this: 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld on the same architectures that use Clang (amd64, arm, arm64, i386). I don't think there's a need for a WITH_LLD src.conf knob, but will add one if desired. 3. Update lld again (most likely to a snapshot from upstream SVN) once it is able to link an unmodified FreeBSD kernel. 4. Modify the boot loader and kernel builds to avoid using features not implemented by lld. 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld hardlink instead of /usr/bin/ld.bfd. 6. Request ports exp-runs and issue a call for testing with 3rd party software. Fix issues found during this process. 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld. There is (some) support for mips and powerpc in lld, but I'm not sure how well tested it is. RISC-V is not yet supported but there is a desire to have a full LLVM-based RISC-V toolchain. I'm not aware of any plan with respect to sparc64 in lld. In any case, I do not plan to address these architectures in the initial lld work. In the near term they will continue to use GNU ld 2.17.50. I'm interested in your comments, questions and concerns about this plan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA>