LLD Build Improvements

Greetings All,

I was wondering what projects seem to improve the most from lld as a linker. It s

seems to mostly be browsers and games but if someone has something else

I would be interested to hear what. The site doesn't really talk about what

projects improve the most so I would be curious to hear what does and

even if possible why.

Nick

As a quick summary, when we moved from gold to lld at Google we found
that nearly every link sped up by a significant amount and took less
memory. The only area that was a concern is gdb_index creation used
more memory and slowed down the link, but it was still faster than
gold. The range of binaries that sped up was everything from simple
unit tests to large binaries.

-eric

If I may take a moment to shamelessly plug the open source project in
my signature, HardenedBSD.

HardenedBSD is an open source downstream derivative of FreeBSD. Our
primary goal is a clean-room re-implementation of the grsecurity
patchset, based solely on publicly-available documentation.

We love and adore PaX RAP. However, its having been covered by one or
more patents and (moreso) its requiring a GPLv3 toolchain is a
non-starter for an OS hoping to assist the efforts of certain members
of the FreeBSD project in migrating to a permissively-licensed
compiler toolchain.

HardenedBSD's future currently lies with the llvm compiler toolchain.
We already make use of non-Cross-DSO CFI and non-Cross-DSO SafeStack.
We are the first enterprise OS to ship with a base operating system
(and select third-party applications offered as binary packages or as
build-it-yourself collection of ports) userland applied with
non-Cross-DSO CFI and non-Cross-DSO SafeStack from the llvm toolchain.

Our next milestone will be Cross-DSO CFI. Tasking exists that are
shared among work porting both Cross-DSO CFI and Cross-DSO SafeStack
(for example, deep integration of the sanitizer framework into the RTLD
and into libc).

Having a basic userland tightly integrated, moving in lockstep, with
the kernel makes working on compiler toolchain-based features all the
more interesting: you get to see your work applied to an entire corpus
at once. No need to hack things together: it's all integrated in a
developer-friendly fashion.

HardenedBSD's future is currently tied to the continued success of the
llvm compiler toolchain. And I'm okay with that. :slight_smile:

Thanks,

As Eric mentioned, lld is generally much faster than GNU linkers, so many companies, especially ones that build large-scale programs (including Google) have migrated to lld and saw a significant reduction in build time, which improved developer productivity. So I’d say that large-scale program development seem to improve the most from lld.

Other interesting area that seem to be benefited from lld is a bootloader and other UEFI programs. UEFI programs are in COFF file format (which is the same as Windows), and it was not easy to build a UEFI program in a host-independent way. There was a hacky way to workaround: for example, you can first build a UEFI program as an ELF program and transplant its text and data segments to an empty COFF file using objcopy. Or, maybe you can just use a Windows machine to link an UEFI program. lld solved the issue because lld is a cross-linker. You can create COFF object files using clang-cl and link the object files using lld/COFF to produce a UEFI program in a very straightforward manner.

Hello,

to echo others, significant benefits have been seen in link times at Sony PlayStation (turnaround time is really important for the large engineering teams working on games). Multithread utilization in lld is good.

Additionally, my experience is that other LLVM features such as LTO and CFI (which requires LTO / Thin LTO) are easier to adopt with lld than alternatives.

Finally, the lld code is well structured, easy to follow and leverages other parts of LLVM where sensible.

Thanks,

Simon