summaryrefslogtreecommitdiffstats
path: root/lld/COFF/SymbolTable.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* COFF: Chagne weak alias' type from SymbolBody** to SymbolBody*. NFC.Rui Ueyama2015-07-011-6/+7
| | | | llvm-svn: 241198
* COFF: Simplify SymbolTable::findLazy. NFC.Rui Ueyama2015-06-301-14/+2
| | | | llvm-svn: 241128
* COFF: Change the order of adding symbols to the symbol table.Rui Ueyama2015-06-301-65/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [opt] Hoist the call throuh SymbolBody::getReplacement out of the inlineChandler Carruth2015-06-291-0/+1
| | | | | | | | | | | | | | | | | | | method to get a SymbolBody and into the callers, and kill now dead includes. This removes the need to have the SymbolBody definition when we're defining the inline method and makes it a better inline method. That was the only reason for a lot of header includes here. Removing these and using forward declarations actually uncovers a bunch of cross-header dependencies that I've fixed while I'm here, and will allow me to introduce some *important* inline code into Chunks.h that requires the definition of ObjectFile. No functionality changed at this point. Differential Revision: http://reviews.llvm.org/D10789 llvm-svn: 240982
* COFF: Fix /export.Rui Ueyama2015-06-291-0/+4
| | | | | | | Mangled dllexported symbols may be defined in a library. If that's the case, we have to read a member file from the library. llvm-svn: 240947
* COFF: Fix logic to find default entry name or subsystem.Rui Ueyama2015-06-291-36/+23
| | | | | | | | | | | | | | | | | | | 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-0/+23
| | | | | | | | | | | | | | | | | | | | 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: Undefined weak aliases are not fatal if /force is given.Rui Ueyama2015-06-281-7/+4
| | | | llvm-svn: 240917
* COFF: Support /force flag.Rui Ueyama2015-06-281-0/+6
| | | | | | | | | | | | | 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 dead code.Rui Ueyama2015-06-261-9/+0
| | | | llvm-svn: 240846
* COFF: Implement /lldmap flag.Peter Collingbourne2015-06-261-0/+11
| | | | | | | | | | | 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-8/+0
| | | | | | | | | | | | | | | | | | | | 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: Better error message for duplicate symbols.Rui Ueyama2015-06-251-1/+2
| | | | | | | Now the symbol table prints out not only symbol names but also file names for duplicate symbols. llvm-svn: 240719
* COFF: Fix a bug of __imp_ symbol.Rui Ueyama2015-06-251-1/+3
| | | | | | | | | | | The change I made in r240620 was not correct. If a symbol foo is defined, and if you use __imp_foo, __imp_foo symbol is automatically defined as a pointer (not just an alias) to foo. Now that we need to create a chunk for automatically-created symbols. I defined LocalImportChunk class for them. llvm-svn: 240622
* COFF: Handle undefined symbols starting with __imp_ in a special way.Rui Ueyama2015-06-251-2/+11
| | | | | | | | | | | | | | | | | | MSVC linker is able to link an object file created from the following code. Note that __imp_hello is not defined anywhere. void hello() { printf("Hello\n"); } extern void (*__imp_hello)(); int main() { __imp_hello(); } Function symbols exported from DLLs are automatically mangled by appending __imp_ prefix, so they have two names (original one and with the prefix). This "feature" seems to simulate that behavior even for non-DLL symbols. This is in my opnion very odd feature. Even MSVC linker warns if you use this. I'm adding that anyway for the sake of compatibiltiy. llvm-svn: 240620
* COFF: Add some error checking to SymbolTable::addCombinedLTOObject().Peter Collingbourne2015-06-241-1/+2
| | | | llvm-svn: 240511
* COFF: Make link order compatible with MSVC link.exe.Rui Ueyama2015-06-231-54/+58
| | | | | | | | | | | | | 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: Combine add{Object,Archive,Bitcode,Import} functions. NFC.Rui Ueyama2015-06-201-47/+19
| | | | llvm-svn: 240229
* COFF: Continue reading object files until converge.Rui Ueyama2015-06-191-1/+5
| | | | | | | | | | | | | | | | | | | 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-1/+10
| | | | | | | | | | | | 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: Rename a function. NFC.Rui Ueyama2015-06-181-2/+2
| | | | llvm-svn: 240031
* COFF: Fix entry point inference bug.Rui Ueyama2015-06-181-0/+9
| | | | | | | Previously, LLD couldn't find a default entry point if it's defined by a library. llvm-svn: 239982
* COFF: Support creating DLLs.Rui Ueyama2015-06-171-0/+8
| | | | | | | | | | | | 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: Symbol resolution for common and comdat symbols defined in bitcode.Peter Collingbourne2015-06-111-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | In the case where either a bitcode file and a regular file or two bitcode files export a common or comdat symbol with the same name, the linker needs to pick one of them following COFF semantics. This patch implements a design for resolving such symbols that pushes most of the work onto either LLD's regular mechanism for resolving common or comdat symbols or the IR linker's mechanism for doing the same. We modify SymbolBody::compare to always prefer non-bitcode symbols, so that during the initial phase of symbol resolution, the symbol table always contains a regular symbol in any case where we need to choose between a regular and a bitcode symbol. In SymbolTable::addCombinedLTOObject, we force export any bitcode symbols that were initially pre-empted by a regular symbol, and later use SymbolBody::compare to choose between the regular symbol in the symbol table and the regular symbol from the combined LTO object file. This design seems to be sound, so long as the resolution mechanism is defined to be commutative and associative modulo arbitrary choices between symbols (which seems to be the case for COFF). Differential Revision: http://reviews.llvm.org/D10329 llvm-svn: 239563
* COFF: Split SymbolTable::addCombinedLTOObject. NFC.Rui Ueyama2015-06-091-29/+36
| | | | llvm-svn: 239418
* COFF: Handle references from LTO object to lazy symbols correctly.Peter Collingbourne2015-06-091-0/+18
| | | | | | | | | | | | | | The code generator may create references to runtime library symbols such as __chkstk which were not visible via LTOModule. Handle these cases by loading the object file from the library, but abort if we end up having loaded any bitcode objects. Because loading the object file may have introduced new undefined references, call reportRemainingUndefines again to detect and report them. Differential Revision: http://reviews.llvm.org/D10332 llvm-svn: 239386
* COFF: Allow the combined LTO object to define new symbols.Peter Collingbourne2015-06-091-4/+10
| | | | | | | | | | The LLVM code generator can sometimes synthesize symbols, such as SSE constants, that are not visible via the LTOModule interface. Allow such symbols so long as they have definitions. Differential Revision: http://reviews.llvm.org/D10331 llvm-svn: 239385
* COFF: Add more log messages.Rui Ueyama2015-06-081-6/+12
| | | | llvm-svn: 239289
* COFF: Print out log messages to stdout.Rui Ueyama2015-06-081-1/+1
| | | | llvm-svn: 239288
* COFF: Read linker directives from bitcode files.Peter Collingbourne2015-06-061-11/+14
| | | | | | Differential Revision: http://reviews.llvm.org/D10285 llvm-svn: 239212
* COFF: /include'd symbols must be preserved.Rui Ueyama2015-06-041-8/+5
| | | | | | | | | Not only entry point symbol but also symbols specified by /include option must be preserved, as they will never be dead-stripped. http://reviews.llvm.org/D10220 llvm-svn: 239005
* COFF: SymbolTable to manage symbols using BumpPtrAllocator.Rui Ueyama2015-06-031-9/+4
| | | | llvm-svn: 238901
* COFF: Initial implementation of link-time optimization.Peter Collingbourne2015-06-011-0/+77
| | | | | | | | This implementation is known to work in very simple cases (see new test case). Differential Revision: http://reviews.llvm.org/D10115 llvm-svn: 238777
* COFF: Define an error category for the linker.Rui Ueyama2015-06-011-4/+7
| | | | | | | | | | | | | Instead of returning non-categorized errors, return categorized errors. All uses of make_dynamic_error_code are removed. Because we don't have error reporting mechanism, I just chose to print out error messages to stderr, and then return an error object. Not sure if that's the right thing to do, but at least it seems practical. http://reviews.llvm.org/D10129 llvm-svn: 238714
* COFF: Add /alternatename option.Rui Ueyama2015-05-311-0/+9
| | | | | | | | | | | | | Previously, this feature was implemented using a special type of undefined symbol, in addition to an intricate way to make the resolver read a virtual file containing that renaming symbols. Now the feature is directly handled by the symbol table. The symbol table has a function, rename(), to rename symbols, whose definition is 4 lines long. Symbol renaming is naturally modeled using Symbol and SymbolBody. llvm-svn: 238696
* COFF: Add /include option.Rui Ueyama2015-05-311-1/+5
| | | | | | | | | It does not involve notions of virtual archives or virtual files, nor store a list of undefined symbols somewhere else to consume them later. We did that before. In this patch, undefined symbols are just added to the symbol table, which now can be done in very few lines of code. llvm-svn: 238681
* COFF: Create LinkerDriver class.Rui Ueyama2015-05-311-1/+1
| | | | | | | | Previously the main linker routine is just a non-member function. We store some context information to the Config object. This patch makes it belong to Driver. llvm-svn: 238677
* COFF: Use range-based for loop.Rui Ueyama2015-05-311-9/+8
| | | | llvm-svn: 238675
* Fix unsafe memory access.Rui Ueyama2015-05-311-1/+3
| | | | llvm-svn: 238669
* COFF: Infer entry symbol name if /entry is not given.Rui Ueyama2015-05-311-9/+34
| | | | | | | | | | `main` is not the only main function in Windows. You can choose one from these four -- {w,}{WinMain,main}. There are four different entry point functions for them, {w,}{WinMain,main}CRTStartup, respectively. The linker needs to choose the right one depending on which `main` function is defined. llvm-svn: 238667
* COFF: Add a new PE/COFF port.Rui Ueyama2015-05-281-0/+175
This is an initial patch for a section-based COFF linker. The patch has 2300 lines of code including comments and blank lines. Before diving into details, you want to start from reading README because it should give you an overview of the design. All important things are written in the README file, so I write summary here. - The linker is already able to self-link on Windows. - It's significantly faster than the existing implementation. The existing one takes 5 seconds to link LLD on my machine, while the new one only takes 1.2 seconds, even though the new one is not multi-threaded yet. (And a proof-of-concept multi- threaded version was able to link it in 0.5 seconds.) - It uses much less memory (250MB vs. 2GB virtual memory space to self-host). - IMHO the new code is much simpler and easier to read than the existing PE/COFF port. http://reviews.llvm.org/D10036 llvm-svn: 238458
OpenPOWER on IntegriCloud