lld 是 LLVM 里的一个子项目，是一个链接器，目前官方还在开发中。在 MacOS 上，其链接时间和优化效果都远超苹果的 ld64。
本文为笔记形式，旨在介绍并了解 lld，对详细内容感兴趣的，链接放在文末。
1、Linker works
“Binds more abstract names to more concrete names, which permits programmers to write code using more abstract names”.
In general concrete representations are higher performance but less flexible.
In practice a tool that glues together the outputs of separate compilation into a single output.
Loading an object from a static library may introduce new undefined references as well as definitions, this may require more objects to be loaded to satisfy these references.
Shared libraries may also be “loaded” to provide symbol definitions and references, although loading just means that the shared library is added as a dependency of the output. The contents of the shared library beyond the symbol table aren’t needed.
Finding all the content for a link is an iterative process that finishes when no more objects are loaded to resolve an undefined reference.
2、Traditional linker
“section” based like traditional linkers which mostly just interlace sections from multiple object files into the output file.
3、lld: Atom based
Features like dead code stripping, reordering functions for locality, and C++ coalescing require the linker to work at a finer grain.
An atom is an indivisible chunk of code or data. An atom has a set of attributes, such as: name, scope, content-type, alignment, etc. An atom also has a list of References. A Reference contains: a kind, an optional offset, an optional addend, and an optional target atom.
The Atom model allows the linker to use standard graph theory models for linking data structures. Each atom is a node, and each Reference is an edge. The feature of dead code stripping is implemented by following edges to mark all live atoms, and then delete the non-live atoms.
Typically each user written function or global variable is an atom. In addition, the compiler may emit other atoms, such as for literal c-strings or floating point constants, or for runtime data structures like dwarf unwind info or pointers to initializers.
3.1、types
There are only four different types of atoms:
- DefinedAtom
95% of all atoms. This is a chunk of code or data
- UndefinedAtom
This is a place holder in object files for a reference to some atom outside the translation unit.During core linking it is usually replaced by (coalesced into) another Atom.
- SharedLibraryAtom
If a required symbol name turns out to be defined in a dynamic shared library (and not some object file). A SharedLibraryAtom is the placeholder Atom used to represent that fact.It is similar to an UndefinedAtom, but it also tracks information about the associated shared library.
- AbsoluteAtom
This is for embedded support where some stuff is implemented in ROM at some fixed address. This atom has no content. It is just an address that the Writer needs to fix up any references to point to.
The way this is modeled in the linker is that a dynamic library contributes no atoms to the initial graph of atoms. Instead, (like static libraries) if there are “undefined” atoms in the master graph of all atoms, then each dynamic library is checked to see if exports the required symbol. If so, a “shared library” atom is instantiated by the by the reader which the linker uses to replace the “undefined” atom.
3.2、linking step
The overall steps in linking are:
-
Command line processing
-
Parsing input files
-
Resolving
-
Passes/Optimizations
-
Generate output file
That is, two or more atoms need to be coalesced into one atom.
The linker support coalescing by-name and by-content. By-name is used for tentative definitions and weak symbols. By-content is used for constant data that can be merged.
When all initial input file atoms have been processed by the resolver, a scan is made to see if there are any undefined atoms in the graph. If there are, the linker scans all libraries (both static and dynamic) looking for definitions to replace the undefined atoms. It is an error if any undefined atoms are left remaining.
参考&推荐阅读
Linker Design: https://lld.llvm.org/design.html
what makes lld so fast？：https://archive.fosdem.org/2019/schedule/event/llvm_lld/attachments/slides/3423/export/events/attachments/llvm_lld/slides/3423/WhatMakesLLDSoFastPresenterNotes.