Lines Matching +full:docs +full:- +full:lld +full:- +full:html
5 ---------------------------
7 You can embed LLD to your program by linking against it and calling the linker's
8 entry point function ``lld::lldMain``.
23 ------------
28 This is a list of design choices we've made for ELF and COFF LLD.
29 We believe that these high-level design choices achieved a right balance
39 to abstract the differences wouldn't be worth its complexity and run-time
47 Therefore, the high-level design matters more than local optimizations.
48 Since we are trying to create a high-performance linker,
61 LLD's handling of archive files (the files with ".a" file extension) is
64 problem is, and how LLD approached the problem.
71 - If the linker visits an object file, the linker links object files to the
74 - If the linker visits an archive file, it checks for the archive file's
78 This algorithm sometimes leads to a counter-intuitive behavior. If you give
85 but that cannot fix the issue of mutually-dependent archive files.
87 Linking mutually-dependent archive files is tricky. You may specify the same
89 you may use the special command line options, `--start-group` and
90 `--end-group`, to let the linker loop over the files between the options until
95 Here is how LLD approaches the problem. Instead of memorizing only undefined
96 symbols, we program LLD so that it memorizes all symbols. When it sees an
99 it. It is doable because LLD does not forget symbols it has seen in archive
102 We believe that LLD's way is efficient and easy to justify.
104 The semantics of LLD's archive handling are different from the traditional
110 ------------------------
113 I'll give you the list of objects and their numbers LLD has to read and process
115 info, which is roughly 2 GB in output size, LLD reads
117 - 17,000 files,
118 - 1,800,000 sections,
119 - 6,300,000 symbols, and
120 - 13,000,000 relocations.
122 LLD produces the 2 GB executable in 15 seconds.
140 -------------------------
142 We will describe the key data structures in LLD in this section. The linker can
150 The linker creates linker-defined symbols as well.
154 - Defined symbols are for all symbols that are considered as "resolved",
156 absolute symbols, linker-created symbols, etc.
157 - Undefined symbols represent undefined symbols, which need to be replaced by
159 - Lazy symbols represent symbols we found in archive file headers
172 been replaced by the defined symbol in-place.
179 - If we add Defined and Undefined symbols, the symbol table will keep the
181 - If we add Defined and Lazy symbols, it will keep the former.
182 - If we add Lazy and Undefined, it will keep the former,
195 Specifically, section-based chunks know how to read relocation tables
225 assign unique, non-overlapping addresses and file offsets to them, and then
232 - processes command line options,
233 - creates a symbol table,
234 - creates an InputFile for each input file and puts all symbols within into
236 - checks if there's no remaining undefined symbols,
237 - creates a writer,
238 - and passes the symbol table to the writer to write the result to a file.
240 Link-Time Optimization
241 ----------------------
251 https://llvm.org/docs/LinkTimeOptimization.html
254 --------
260 Windows executables or DLLs are not position-independent; they are
283 Note that this run-time relocation mechanism is much simpler than ELF.
293 ICF is an optimization to reduce output size by merging read-only sections
294 by not only their names but by their contents. If two read-only sections
309 LLD works fine with ICF for example.
312 ----------