diff options
Diffstat (limited to 'docs/NewLLD.rst')
| -rw-r--r-- | docs/NewLLD.rst | 46 |
1 files changed, 5 insertions, 41 deletions
diff --git a/docs/NewLLD.rst b/docs/NewLLD.rst index cffea7c02dea..67f6b368b0e4 100644 --- a/docs/NewLLD.rst +++ b/docs/NewLLD.rst @@ -1,42 +1,6 @@ The ELF and COFF Linkers ======================== -We started rewriting the ELF (Unix) and COFF (Windows) linkers in May 2015. -Since then, we have been making a steady progress towards providing -drop-in replacements for the system linkers. - -Currently, the Windows support is mostly complete and is about 2x faster -than the linker that comes as a part of Micrsoft Visual Studio toolchain. - -The ELF support is in progress and is able to link large programs -such as Clang or LLD itself. Unless your program depends on linker scripts, -you can expect it to be linkable with LLD. -It is currently about 1.2x to 2x faster than GNU gold linker. -We aim to make it a drop-in replacement for the GNU linker. - -We expect that FreeBSD is going to be the first large system -to adopt LLD as the system linker. -We are working on it in collaboration with the FreeBSD project. - -The linkers are notably small; as of October 2016, -the COFF linker is about 7k lines and the ELF linker is about 18k lines, -while gold is 165K lines. - -The linkers are designed to be as fast and simple as possible. -Because it is simple, it is easy to extend to support new features. -It already supports several advanced features such section garbage -collection and identical code folding. - -The COFF linker supports i386, x86-64 and ARM. The ELF linker supports -i386, x86-64, x32, MIPS32, MIPS64, PowerPC, AMDGPU, ARM and Aarch64, -although the quality varies depending on platform. By default, LLD -provides support for all targets because the amount of code we have for -each target is so small. We do not even provide a way to disable -targets at compile time. - -There are a few key design choices that we made to achieve these goals. -We will describe them in this document. - The ELF Linker as a Library --------------------------- @@ -126,7 +90,7 @@ between speed, simplicity and extensibility. Visiting the same archive files multiple makes the linker slower. - Here is how LLD approached the problem. Instead of memorizing only undefined symbols, + Here is how LLD approaches the problem. Instead of memorizing only undefined symbols, we program LLD so that it memorizes all symbols. When it sees an undefined symbol that can be resolved by extracting an object file from an archive file it previously visited, it immediately extracts the file and link it. @@ -169,7 +133,7 @@ it would slow down the linker by 10%. So, don't do that. On the other hand, you don't have to pursue efficiency when handling files. -Important Data Strcutures +Important Data Structures ------------------------- We will describe the key data structures in LLD in this section. @@ -216,7 +180,7 @@ Once you understand their functions, the code of the linker should look obvious * SymbolTable SymbolTable is basically a hash table from strings to Symbols - with a logic to resolve symbol conflicts. It resolves conflicts by symbol type. + with logic to resolve symbol conflicts. It resolves conflicts by symbol type. - If we add Defined and Undefined symbols, the symbol table will keep the former. - If we add Defined and Lazy symbols, it will keep the former. @@ -269,11 +233,11 @@ There are mainly three actors in this linker. * Driver - The linking process is driven by the driver. The driver + The linking process is driven by the driver. The driver: - processes command line options, - creates a symbol table, - - creates an InputFile for each input file and put all symbols in it into the symbol table, + - creates an InputFile for each input file and puts all symbols within into the symbol table, - checks if there's no remaining undefined symbols, - creates a writer, - and passes the symbol table to the writer to write the result to a file. |