0
Files
src/docs/mac_lld.md
Nico Weber 44f066e227 Update mac_lld.md
We use lld on iOS too.

This should have been in
https://chromium-review.googlesource.com/c/chromium/src/+/3206018

Thanks to Andrew Kaster for noticing!

Bug: 1149587
Change-Id: I9d77fdeff06a9c32976011e4d382ae7ce3c0b5bc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3873433
Reviewed-by: Mark Mentovai <mark@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1043052}
2022-09-05 02:36:13 +00:00

72 lines
2.9 KiB
Markdown

# LLD for Mac builds
Like on most other platforms, Chromium uses the LLD linker on iOS and macOS.
This is a recent change. If things go well, it will ship in m95,
but we might discover showstopper bugs that delay things a bit.
## Background
Chromium uses [LLD](https://lld.llvm.org/) as linker on all platforms.
LLD is faster than other ELF linkers (ELF
is the executable file format used on most OSs, including Linux, Android,
Chrome OS, Fuchsia), and it's faster than other COFF linkers (the executable
file format on Windows).
LLD is currently 3-4x as fast as ld64, the macOS system linker, at linking
Chromium Framework in symbol\_level=0 release builds, despite ld64 being already
fast.
LLD has advantages unrelated to speed, too:
- It's developed in the LLVM repository, and we ship it in our clang package.
We can fix issues upstream and quickly deploy fixed versions, instead of
having to wait for Xcode releases (which is where ld64 ships).
- For the same reason, it has a much simpler LTO setup: Clang and LLD both link
in the same LLVM libraries that are built at the same revision, and compiler
and linker bitcodes are interopable for that reason. With ld64, the LTO code
has to be built as a plugin that's loaded by the linker.
- LLD/Mach-O supports "LLVM-y" features that the ELF and COFF LLDs support as
well, such as thin archives, colored diagnostics, and response files
(ld64 supports this too as of Xcode 12, but we had to wait many years for it,
and it's currently [too crashy](https://crbug.com/1147968) to be usable).
- While LLD for ELF, LLD for COFF, and LLD for MachO are mostly independent
codebases, they all use LLVM libraries. That gives them similar behavior.
Using LLD unifies the build across platforms somewhat.
For that reason, we moved to LLD for iOS and macOS builds.
Just like the LLD ELF port tries to be commandline-compatible with other ELF
linkers and the LLD COFF port tries to be commandline-compatible with the
Visual Studio linker link.exe, the LLD Mach-O port tries to be
commandline-compatible with ld64. This means LLD accepts different flags on
different platforms.
## Current status and known issues
LLD is used by default in almost all build configurations. All
tests on all bots are passing, both Intel and Arm.
There are a few open issues:
- LLD implements deduplication (aka "ICF"), but we don't yet
enable it in arm builds ([bug](https://crbug.com/1253924)).
- LLD doesn't yet implement call graph profile sort.
- LTO support in LLD/macOS isn't complete yet, and we don't use LTO
on macOS yet for that reason.
## Hacking on LLD
If you want to work on LLD, follow [this paragraph](clang.md#Using-a-custom-clang-binary).
## Creating stand-alone repros for bugs
For simple cases, LLD's `--reproduce=foo.tar` flag / `LLD_REPRODUCE=foo.tar`
env var is sufficient.
See "Note to self:" [here](https://bugs.llvm.org/show_bug.cgi?id=48657#c0) for
making a repro file that involved the full app and framework bundles.