Lines Matching +full:- +full:- +full:files
5 ---------------------------
11 files. The function is guaranteed to return as long as you do not pass corrupted
12 or malicious object files. A corrupted file could cause a fatal error or SEGV.
14 files in the usual way and give them to the linker. It is naturally expected to
23 ------------
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
63 We'll describe how the traditional Unix linker handles archive files, what the
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
75 symbol table and extracts all object files that have definitions for any
78 This algorithm sometimes leads to a counter-intuitive behavior. If you give
79 archive files before object files, nothing will happen because when the linker
81 files are extracted from the first archive file, and the link is done at that
84 You can fix the problem by reordering the files,
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
93 Visiting the same archive files multiple times makes the linker slower.
100 files.
105 Unix's. You can observe it if you carefully craft archive files to exploit
110 ------------------------
117 - 17,000 files,
118 - 1,800,000 sections,
119 - 6,300,000 symbols, and
120 - 13,000,000 relocations.
137 when handling files.
140 -------------------------
149 They are created for symbols in object files or archive files.
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
164 files, it replaces an existing Symbol with the "best" Symbol for its symbol
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
201 input files as Chunks for ELF. Instead, we directly use the input section
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 ----------------------
243 LTO is implemented by handling LLVM bitcode files as object files.
244 The linker resolves symbols in bitcode files normally. If all symbols
246 with all bitcode files to convert them to one big regular ELF/COFF file.
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
312 ----------