summaryrefslogtreecommitdiffstats
path: root/lld/COFF/Driver.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* COFF: Fix a bug that /delayload was case-sensitive.Rui Ueyama2015-07-031-1/+1
| | | | llvm-svn: 241316
* COFF: Fix /base option.Rui Ueyama2015-07-031-0/+3
| | | | | | | | | | | Previously, __ImageBase symbol got a different value than the one specified by /base:<number> because the symbol was created in the SymbolTable's constructor. When the constructor is called, no command line options are processed yet, so the symbol was created always with the initial value. This caused wrong relocations and thus caused mysterious crashes of some executables linked by LLD. llvm-svn: 241313
* COFF: Merge SymbolTable::find{,Symbol}. NFCRui Ueyama2015-07-021-2/+2
| | | | llvm-svn: 241238
* COFF: Infer entry point as early as possible, but not too early.Rui Ueyama2015-07-021-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | On Windows, we have four different main functions, {w,}{main,WinMain}. The linker has to choose a corresponding entry point function among {w,}{main,WinMain}CRTStartup. These entry point functions are defined in the standard library. The linker resolves one of them by looking at which main function is defined and adding a corresponding undefined symbol to the symbol table. Object files containing entry point functions conflicts each other. For example, we cannot resolve both mainCRTStartup and WinMainCRTStartup because other symbols defined in the files conflict. Previously, we inferred CRT function name at the very end of name resolution. I found that that is sometimes too late. If the linker already linked one of these four archive member objects, it's too late to change the decision. The right thing to do here is to infer entry point name after adding all symbols from command line files and before adding any other files (which are specified by directive sections). This patch does that. llvm-svn: 241236
* COFF: Resolve AlternateNames using weak aliases.Rui Ueyama2015-07-021-12/+11
| | | | | | | | Previously, we use SymbolTable::rename to resolve AlternateName symbols. This patch is to merge that mechanism with weak aliases, so that we remove that function. llvm-svn: 241230
* COFF: Change GCRoot member type from StringRef to Undefined. NFC.Rui Ueyama2015-07-021-1/+1
| | | | | | | | | I think Undefined symbols are a bit more convenient than StringRefs since SymbolBodies are handles for symbols. You can get resolved symbols for undefined symbols just by calling getReplacmenet without looking up the symbol table. llvm-svn: 241214
* COFF: Simplify and rename findMangle. NFC.Rui Ueyama2015-07-021-40/+19
| | | | | | | | | | Occasionally we have to resolve an undefined symbol to its mangled symbol. Previously, we did that on calling side of findMangle by explicitly updating SymbolBody. In this patch, mangled symbols are handled as weak aliases for undefined symbols. llvm-svn: 241213
* COFF: Simplify SymbolTable::findLazy. NFC.Rui Ueyama2015-06-301-1/+2
| | | | llvm-svn: 241128
* COFF: Change the order of adding symbols to the symbol table.Rui Ueyama2015-06-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the order of adding symbols to the symbol table was simple. We have a list of all input files. We read each file from beginning of the list and add all symbols in it to the symbol table. This patch changes that order. Now all archive files are added to the symbol table first, and then all the other object files are added. This shouldn't change the behavior in single-threading, and make room to parallelize in multi-threading. In the first step, only lazy symbols are added to the symbol table because archives contain only Lazy symbols. Member object files found to be necessary are queued. In the second step, defined and undefined symbols are added from object files. Adding an undefined symbol to the symbol table may cause more member files to be added to the queue. We simply continue reading all object files until the queue is empty. Finally, new archive or object files may be added to the queues by object files' directive sections (which contain new command line options). The above process is repeated until we get no new files. Symbols defined both in object files and in archives can make results undeterministic. If an archive is read before an object, a new member file gets linked, while in the other way, no new file would be added. That is the most popular cause of an undeterministic result or linking failure as I observed. Separating phases of adding lazy symbols and undefined symbols makes that deterministic. Adding symbols in each phase should be parallelizable. llvm-svn: 241107
* COFF: Handle mangled entry symbol name.Rui Ueyama2015-06-291-0/+10
| | | | | | | | | | Compilers recognize "main" function and don't mangle its name. But if you use a different function as a user-defined entry name, and if you didn't define that function with extern C, your entry point function name is mangled. And the linker has to be able to find that. This is relatively rare but can happen. llvm-svn: 240953
* COFF: Create an empty file for /pdb.Rui Ueyama2015-06-291-0/+4
| | | | | | | | Most build system depends on existence or time stamp of a file. This patch is to create an empty file for /pdb:<filename> option just to satisfy some build rules. llvm-svn: 240948
* COFF: Fix logic to find default entry name or subsystem.Rui Ueyama2015-06-291-20/+34
| | | | | | | | | | | | | | | | | | | The previous logic to find default entry name or subsystem does not seem correct (i.e. was not compatible with MSVC linker). Previously, default entry name was inferred from CRT functions and user-defined entry functions. Subsystem was inferred from CRT functions. Default entry name and subsystem are now inferred based on the following table. Note that we no longer use CRT functions to infer them. Entry name Subsystem main mainCRTStartup console wmain wmainCRTStartup console WinMain WinMainCRTStartup windows wWinMain wWinMainCRTStartup windows llvm-svn: 240922
* COFF: Allow mangled symbols as arguments for /export.Rui Ueyama2015-06-281-4/+15
| | | | | | | | | | | | | | | | | | | | Usually dllexported symbols are defined with 'extern "C"', so identifying them is easy. We can just do hash table lookup to look up exported symbols. However, C++ non-member functions are also allowed to be exported, and they can be specified with unmangled name. So, if /export:foo is given, we need to look up not only "foo" but also its all mangled names. In MSVC mangling scheme, that means that we need to look up any symbol which starts with "?foo@@Y". In this patch, we scan the entire symbol table to search for a mangled symbol. The symbol table is a DenseMap, and that doesn't support table lookup by string prefix. This is of course very inefficient. But that should be probably OK because the user should always add 'extern "C"' to dllexported symbols. llvm-svn: 240919
* COFF: Add a comment.Rui Ueyama2015-06-281-1/+2
| | | | llvm-svn: 240916
* COFF: Add /noentry flag.Rui Ueyama2015-06-281-3/+12
| | | | | | | This option is sometimes used to create a resource-only DLL that doesn't need any initialization. llvm-svn: 240915
* COFF: Support /force flag.Rui Ueyama2015-06-281-0/+4
| | | | | | | | | | | | | This option is to ignore remaining undefined symbols and force the linker to create an output file anyways. The existing code assumes that there's no undefined symbol after reportRemainingUndefines(). That assumption is legitimate. I also don't want to mess up the existing code for this minor feature. In order to keep it as is, remaining undefined symbols are replaced with dummy defined symbols. llvm-svn: 240913
* COFF: Remove a function that doesn't do much itself. NFC.Rui Ueyama2015-06-281-1/+1
| | | | llvm-svn: 240901
* COFF: Handle LINK environment variable.Rui Ueyama2015-06-281-1/+1
| | | | | | | If LINK is defined and not empty, it's supposed to contain command line options. llvm-svn: 240900
* COFF: Use vector::erase instead of reallocating entire vector. NFC.Rui Ueyama2015-06-261-6/+6
| | | | llvm-svn: 240862
* Fix MSVC build.Peter Collingbourne2015-06-261-2/+2
| | | | llvm-svn: 240818
* COFF: Implement /lldmap flag.Peter Collingbourne2015-06-261-0/+12
| | | | | | | | | | | This flag can be used to produce a map file, which is essentially a list of objects linked into the final output file together with the RVAs of their symbols. Because our format differs from MSVC's we expose it as a separate flag. Differential Revision: http://reviews.llvm.org/D10773 llvm-svn: 240812
* COFF: Change symbol resolution order for entry and /include.Rui Ueyama2015-06-261-20/+20
| | | | | | | | | | | | | | | | | | | | We were resolving entry symbols and /include'd symbols after all other symbols are resolved. But looks like it's too late. I found that it causes some program to fail to link. Let's say we have an object file A which defines symbols X and Y in an archive. We also have another file B after A which defines X, Y and _DLLMainCRTStartup in another archive. They conflict each other, so either A or B can be linked. If we have _DLLMainCRTStartup as an undefined symbol, file B is always chosen. If not, there's a chance that A is chosen. If the linker find it needs _DllMainCRTStartup after that, it's too late. This patch adds undefined symbols to the symbol table as soon as possible to fix the issue. llvm-svn: 240757
* COFF: Rename /opt:icf -> /opt:lldicf.Rui Ueyama2015-06-251-1/+1
| | | | | | | | ICF implemented in LLD is so experimental that we don't want to enable that even if /opt:icf option is passed. I'll rename it back once the feature is complete. llvm-svn: 240721
* COFF: Initial implementation of Identical COMDAT Folding.Rui Ueyama2015-06-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Identical COMDAT Folding (ICF) is an optimization to reduce binary size by merging COMDAT sections that contain the same metadata, actual data and relocations. MSVC link.exe and many other linkers have this feature. LLD achieves on per with MSVC in terms produced binary size with this patch. This technique is pretty effective. For example, LLD's size is reduced from 64MB to 54MB by enaling this optimization. The algorithm implemented in this patch is extremely inefficient. It puts all COMDAT sections into a set to identify duplicates. Time to self-link with/without ICF are 3.3 and 320 seconds, respectively. So this option roughly makes LLD 100x slower. But it's okay as I wanted to achieve correctness first. LLD is still able to link itself with this optimization. I'm going to make it more efficient in followup patches. Note that this optimization is *not* entirely safe. C/C++ require different functions have different addresses. If your program relies on that property, your program wouldn't work with ICF. However, it's not going to be an issue on Windows because MSVC link.exe turns ICF on by default. As long as your program works with default settings (or not passing /opt:noicf), your program would work with LLD too. llvm-svn: 240519
* COFF: Make link order compatible with MSVC link.exe.Rui Ueyama2015-06-231-15/+13
| | | | | | | | | | | | | Previously, we added files in directive sections to the symbol table as we read the sections, so the link order was depth-first. That's not compatible with MSVC link.exe nor the old LLD. This patch is to queue files so that new files are added to the end of the queue and processed last. Now addFile() doesn't parse files nor resolve symbols. You need to call run() to process queued files. llvm-svn: 240483
* COFF: Fix null pointer dereference.Peter Collingbourne2015-06-231-1/+1
| | | | llvm-svn: 240447
* Update for LLVM API change to return by InputArgList directly (rather than ↵David Blaikie2015-06-221-40/+46
| | | | | | by pointer) from ParseArgs llvm-svn: 240347
* Fix missed formatting in prior commit (mostly 80 cols violation and some ↵David Blaikie2015-06-221-2/+2
| | | | | | whitespace around *) llvm-svn: 240346
* COFF: Support delay-load import tables.Rui Ueyama2015-06-211-0/+6
| | | | | | | | | | | | | | | | DLLs are usually resolved at process startup, but you can delay-load them by passing /delayload option to the linker. If a /delayload is specified, the linker has to create data which is similar to regular import table. One notable difference is that the pointers in a delay-load import table are originally pointing to thunks that resolves themselves. Each thunk loads a DLL, resolve its name, and then overwrites the pointer with the result so that subsequent function calls directly call a desired function. The linker has to emit thunks. llvm-svn: 240250
* ArrayRef-ify Driver::parse and related functions.David Blaikie2015-06-211-7/+7
| | | | llvm-svn: 240236
* COFF: Fix precedence between LIB and /libpath.Rui Ueyama2015-06-191-11/+9
| | | | | | | /libpath should take precedence over LIB. Previously, LIB took precedence over /libpath. llvm-svn: 240182
* COFF: Add search paths in the correct order.Rui Ueyama2015-06-191-5/+2
| | | | | | Previously, we added search paths in reverse order. llvm-svn: 240180
* COFF: Continue reading object files until converge.Rui Ueyama2015-06-191-31/+36
| | | | | | | | | | | | | | | | | | | In this linker model, adding an undefined symbol may trigger chain reactions. It may trigger a Lazy symbol to read a new file. A new file may contain a directive section, which may contain various command line options. Previously, we didn't handle chain reactions well. We visited /include'd symbols only once, so newly-added /include symbols were ignored. This patch fixes that bug. Now, the symbol table is versioned; every time the symbol table is updated, the version number is incremented. We repeat adding undefined symbols until the version number does not change. It is guaranteed to converge -- the number of undefined symbol in the system is finite, and adding the same undefined symbol more than once is basically no-op. llvm-svn: 240177
* COFF: Don't add new undefined symbols for /alternatename.Rui Ueyama2015-06-191-6/+0
| | | | | | | | | | | | Alternatename option is in the form of /alternatename:<from>=<to>. It's effect is to resolve <from> as <to> if <from> is still undefined at end of name resolution. If <from> is not undefined but completely a new symbol, alternatename shouldn't do anything. Previously, it introduced a new undefined symbol for <from>, which resulted in undefined symbol error. llvm-svn: 240161
* COFF: Add /nodefaultlib and /merge for .drectve.Rui Ueyama2015-06-181-0/+6
| | | | llvm-svn: 240077
* COFF: Handle /include in .drectve.Rui Ueyama2015-06-181-6/+15
| | | | | | | | | | | | | We don't want to insert a new symbol to the symbol table while reading a .drectve section because it's going to be too complicated. That we are reading a directive section means that we are currently reading some object file. Adding a new undefined symbol to the symbol table can trigger a library file to read a new file, so it would make the call stack too deep. In this patch, I add new symbol names to a list to resolve them later. llvm-svn: 240076
* COFF: Allow identical alternatename options.Rui Ueyama2015-06-181-3/+3
| | | | | | | | Alternatename option is in the form of /alternatename:<from>=<to>. It is an error if there are two options having the same <from> but different <to>. It is *not* an error if both are the same. llvm-svn: 240075
* COFF: Unknown options in .drectve section is an error.Rui Ueyama2015-06-181-25/+29
| | | | | | | | | We skip unknown options in the command line with a warning message being printed out, but we shouldn't do that for .drectve section. The section is not visible to the user. We should handle unknown options as an error. llvm-svn: 240067
* COFF: Handle /failifmismatch in the same manner as other options.Rui Ueyama2015-06-181-6/+6
| | | | | | No functionality change intended. llvm-svn: 240061
* COFF: Add /implib option.Rui Ueyama2015-06-181-0/+4
| | | | llvm-svn: 240045
* COFF: Handle /alternatename in .drectve section.Rui Ueyama2015-06-181-22/+28
| | | | llvm-svn: 240037
* COFF: Support /manifest{,uac,dependency,file} options.Rui Ueyama2015-06-181-1/+42
| | | | | | | | | | | | | | | The linker has to create an XML file for each executable. This patch supports that feature. You can optionally embed an XML file to an executable as .rsrc section. If you choose to do that (by passing /manifest:embed option), the linker has to create a textual resource file containing an XML file, compile that using rc.exe to a binary resource file, conver that resource file to a COFF file using cvtres.exe, and then link that COFF file. This patch implements that feature too. llvm-svn: 239978
* COFF: Create import library files.Rui Ueyama2015-06-171-0/+5
| | | | | | | | | | | | | | | | | | | | On Windows, we have to create a .lib file for each .dll. When linking against DLLs, the linker doesn't use the DLL files, but instead read a list of dllexported symbols from corresponding lib files. A library file containing descriptors of a DLL is called an import library file. lib.exe has a feature to create an import library file from a module-definition file. In this patch, we create a module-definition file and pass that to lib.exe. We eventually want to create an import library file by ourselves to eliminate dependency to lib.exe. For now, we just use the MSVC tool. llvm-svn: 239937
* COFF: Support module-definition files.Rui Ueyama2015-06-171-0/+12
| | | | | | | | | | | | | | | | Module-definition files (.def files) are yet another way to specify parameters to the linker. You can write a list of dllexported symbols in module-definition files instead of using /export command line option. It also supports a few more directives. The parser code is taken from lib/Driver/WinLinkModuleDef.cpp with the following modifications. - variable names are updated to comply with the LLVM coding style. - Instead of returning parsing results as "directive" objects, it updates Config object directly. llvm-svn: 239929
* COFF: Support creating DLLs.Rui Ueyama2015-06-171-7/+49
| | | | | | | | | | | | DLL files are in the same format as executables but they have export tables. The format of the export table is described in PE/COFF spec section 5.3. A new class, EdataContents, takes care of creating chunks for export tables. What we need to do is to parse command line flags for dllexports, and then instantiate the class to create chunks. For the writer, export table chunks are opaque data -- it just add chunks to .edata section. llvm-svn: 239869
* COFF: Add miscellaneous boolean flags.Rui Ueyama2015-06-161-1/+15
| | | | llvm-svn: 239864
* COFF: Support base relocations.Rui Ueyama2015-06-151-0/+4
| | | | | | | | | | | | | | | | | | | PE/COFF executables/DLLs usually contain data which is called base relocations. Base relocations are a list of addresses that need to be fixed by the loader if load-time relocation is needed. Base relocations are in .reloc section. We emit one base relocation entry for each IMAGE_REL_AMD64_ADDR64 relocation. In order to save disk space, base relocations are grouped by page. Each group is called a block. A block starts with a 32-bit page address followed by 16-bit offsets in the page. That is more efficient representation of addresses than just an array of 32-bit addresses. llvm-svn: 239710
* COFF: Support Windows resource files.Rui Ueyama2015-06-141-20/+46
| | | | | | | | | | | Resource files are data files containing i18n messages, icon images, etc. MSVC has a tool to convert a resource file to a regular COFF file so that you can just link that file to embed resources to an executable. However, you can directly pass resource files to the linker. If you do that, the linker invokes the tool automatically. This patch implements that feature. llvm-svn: 239704
* Update for llvm api change.Rafael Espindola2015-06-131-1/+0
| | | | llvm-svn: 239671
* COFF: Implement /lib using LibDriver.Peter Collingbourne2015-06-091-0/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D10347 llvm-svn: 239436
OpenPOWER on IntegriCloud