summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/PECOFF/WriterPECOFF.cpp
Commit message (Collapse)AuthorAgeFilesLines
* COFF: Remove the old COFF linker and make link an alias to link2.Rui Ueyama2015-08-061-1417/+0
| | | | | | It's time to remove old COFF linker because the new one is now complete. llvm-svn: 244226
* Fix undefined behaviour exposed by the new -Wshift-negative-value warning.Davide Italiano2015-07-071-1/+1
| | | | llvm-svn: 241530
* Revert r234649 "PECOFF: Use C++11 braced init list to make Version objects."Nico Weber2015-04-111-6/+8
| | | | | | | | | | | | | | This doesn't compile with MSVC 2013: include\lld/ReaderWriter/PECOFFLinkingContext.h(356) : error C2797: 'lld::PECOFFLinkingContext::_imageVersion': list initialization inside member initializer list or non-static data member initializer is not implemented include\lld/ReaderWriter/PECOFFLinkingContext.h(357) : error C2797: 'lld::PECOFFLinkingContext::_imageVersion': list initialization inside member initializer list or non-static data member initializer is not implemented llvm-svn: 234676
* PECOFF: Use C++11 braced init list to make Version objects.Rui Ueyama2015-04-101-8/+6
| | | | llvm-svn: 234649
* Do s/_context/_ctx/g globally.Rui Ueyama2015-04-101-4/+4
| | | | | | | | I believe this patch eliminates all remaining uses of _context or _linkingContext variable names. Consistent naming improves readability. llvm-svn: 234645
* Use alignment values everywhere instead of log2.Rui Ueyama2015-03-261-2/+2
| | | | | | | | This patch defines implicit conversion between integers and PowerOf2 instances, so uses of the classes is now implicit and look like regular integers. Now we are ready to remove the scaffolding. llvm-svn: 233245
* Remove implicit constructor and operator int from PowerOf2.Rui Ueyama2015-03-261-3/+3
| | | | | | | | | | This patch is to make instantiation and conversion to an integer explicit, so that we can mechanically replace all occurrences of the class with integer in the next step. Now get() returns an alignment value rather than its log2 value. llvm-svn: 233242
* Fix the local variable naming I used in r231765 to follow the LLD codingChandler Carruth2015-03-101-4/+4
| | | | | | conventions. Sorry for missing this before I committed the patch! llvm-svn: 231766
* Fix a bug where the code would use subscript a std::vector with the sizeChandler Carruth2015-03-101-6/+7
| | | | | | | | | | | | | | | | | | of the vector. For a vector 'v', '&v[v.size()]' isn't a valid way to compute a pointer one-past-the-end of the vector. Instead, write the loop in terms of iterators and save the beginning iterator. Once we have that we can compute the beginning pointer from the beginning iterator, and compute the distance which we should increment the beginning pointer by subtracting the iterators. What might be simpler would be to convert the function accepting a raw pointer for begin and end to accept iterators or a range or some other construct, but I wanted to keep this to a minimal bug-fix change. This fixes a crash on any debug STL implementation which checks for indexing out of bounds. llvm-svn: 231765
* PECOFF: Define and use BaseReloc type instead of std::pair.Rui Ueyama2015-03-081-33/+29
| | | | | | | "first" and "second" are not easy to memorize. Define a type to use meaningful names. llvm-svn: 231614
* PECOFF: Fix off-by-one error.Rui Ueyama2015-03-081-1/+1
| | | | | | We accidentally skipped the last base relocation entry for each block. llvm-svn: 231586
* PECOFF: Parallelize base relocation creation.Rui Ueyama2015-03-081-29/+31
| | | | | | | | | | | | | | | | | If an output is large, its base relocation section can be also large. For example, chrome.dll is almost 300 MB, and it has about 9 million base relocations. Creating the section took 1.5 seconds on my machine. This patch changes the way to create the section so that we can use parallel_sort to group base relocations by high bits. This change makes the linker almost 4% faster for the above test case on my machine. If I replace parallel_sort with std::sort, performance remains the same, so single thread performance should remain the same. This has no functionality change. The output should be identical as before. llvm-svn: 231585
* PECOFF: Optimize the writer using parallel_for.Rui Ueyama2015-03-061-8/+11
| | | | | | | | | Previously applying 1 million relocations took about 2 seconds on my Xeon 2.4GHz 8 core workstation. After this patch, it takes about 300 milliseconds. As a result, time to link chrome.dll becomes 23 seconds to 21 seconds. llvm-svn: 231454
* Remove include/lld/Core/Endian.h and use llvm/Support/Endian.h instead.Rui Ueyama2015-03-021-1/+2
| | | | llvm-svn: 231005
* Add {read,write}{16,32,64}{le,be} functions.Rui Ueyama2015-02-271-5/+6
| | | | | | | | | | | | | | Nothing wrong with reinterpret_cast<llvm::support::ulittle32_t *>(loc), but that's redundant and not great from readability point of view. The new functions are wrappers for that kind of reinterpet_casts. Surprisingly or unsurprisingly, there was no use of big endian read and write. {read,write}{16,32,64}be have no user. But I think they still worth to be there in the header for completeness. http://reviews.llvm.org/D7927 llvm-svn: 230725
* PECOFF: Fix base relocation for ImageBase.Rui Ueyama2015-02-201-1/+7
| | | | | | | | | | | | | | This is yet another edge case of base relocation for symbols. Absolute symbols are in general not target of base relocation because absolute atom is a way to point to a specific memory location. In r229816, I removed entries for absolute atoms from the base relocation table (so that they won't be fixed by the loader). However, there was one exception -- ImageBase. ImageBase points to the start address of the current image in memory. That needs to be fixed up at load time. This patch is to treat the symbol in a special manner. llvm-svn: 229961
* PECOFF: Fix base relocation for an absolute symbol.Rui Ueyama2015-02-191-0/+2
| | | | | | | | | | | | Previously we wrongly emitted a base relocation entry for an absolute symbol. That made the loader to rewrite some instruction operands with wrong values only when a DLL is not loaded at the default address. That caused a misterious crash of some executable. Absolute symbols will of course never change value wherever the binary is loaded to memory. We shouldn't emit base relocations for absolute symbols. llvm-svn: 229816
* PECOFF: Fix dummy symbol table in executable.Rui Ueyama2015-02-121-0/+4
| | | | | | | | | | | If the name field of a symbol table entry is all zero, it's interpreted as it's pointing to the beginning of the string table. The first four bytes of the string table is the size field, so dumpbin dumps that number as an ASCIZ string. This patch fills a dummy value to name field. llvm-svn: 228971
* PECOFF: make dumpbin tool happy.Rui Ueyama2015-02-121-8/+17
| | | | | | | | | | | | | | | | | | | | | The dumpbin tool in the MSVC toolchain cannot handle an executable created by LLD if the executable contains a long section name. In PE/COFF, a section name is stored to a section table entry. Because the section name field in the table is only 8 byte long, a name longer than that is stored to the string table and the offset in the string table is stored to the section table entry instead. In order to look up a string from the string table, tools need to handle the symbol table, because the string table is defined as it immediately follows the symbol table. And seems the dumpbin doesn't like zero-length symbol table. This patch teaches LLD how to emit a dummy symbol table. The dummy table has one dummy entry in it. llvm-svn: 228900
* PECOFF: Fix I386_DIR32 relocation to an absolute symbolRui Ueyama2015-02-051-2/+6
| | | | | | | | | | | | | Previously, we incorrectly added the image base address to an absolute symbol address (that calculation doesn't make any sense) if an IMAGE_REL_I386_DIR32 relocation is applied to an absolute symbol. This patch fixes the issue. With this fix, we can link Bochs using LLD. (Choosing Bochs has no special meaining -- I just picked it up as a test program and found it didn't work.) This also fixes one of the issues we currently have to link Chromium using LLD. llvm-svn: 228279
* Fix five of the shared library build targetsGreg Fitzgerald2015-01-211-1/+1
| | | | | | | | | | | | | | | | | | Before this patch there was a cyclic dependency between lldCore and lldReaderWriter. Only lldConfig could be built as a shared library. * Moved Reader and Writer base classes into lldCore. * The following shared libraries can now be built: lldCore lldYAML lldNative lldPasses lldReaderWriter Differential Revision: http://reviews.llvm.org/D7105 From: Greg Fitzgerald <garious@gmail.com> llvm-svn: 226732
* PE/COFF: rework how we handle base relocationsSaleem Abdulrasool2015-01-161-51/+59
| | | | | | | | | | | | | Generalise the base relocation handling slightly to support multiple base relocation types in PE/COFF. This is necessary to generate proper executables for WoA. Track the base relocation type from the decision that we need a base relocation to the point where we emit the base relocation into base relocation directory. Remove an outdated TODO item while in the area. llvm-svn: 226335
* PE/COFF: use dyn_cast for the check of the targetSaleem Abdulrasool2015-01-161-1/+1
| | | | | | | | | | The target may be a synthetic symbol like __ImageBase. cast_or_null will ensure that the atom is a DefinedAtom, which is not guaranteed, which was the original reason for the cast_or_null. Switch this to dyn_cast, which should enable building of executables for WoA. Unfortunately, the issue of missing base relocations still needs to be investigated. llvm-svn: 226246
* PE/COFF: teach ARMNT backend about ADDR32NB for exportsSaleem Abdulrasool2015-01-071-0/+3
| | | | | | | | | This adds the ability to export symbols from a DLL built for ARMNT. Add this support first to help work towards adding support for import thunks on Windows on ARM. In order to generate the exports, add support for IMAGE_REL_ARM_ADDR32NB relocations. llvm-svn: 225339
* PECOFF: adjust the entry point on ARM NTSaleem Abdulrasool2015-01-041-3/+9
| | | | | | | | | ARM NT assumes a purely THUMB execution, and as such requires that the address of entry point is adjusted to indicate a thumb entry point. Unconditionally adjust the AddressOfEntryPoint in the PE header for PE/COFF ARM as we only support ARM NT at the moment. llvm-svn: 225139
* ReaderWriter: adjust ARM target addresses for execSaleem Abdulrasool2015-01-031-1/+8
| | | | | | | | | | | | ARM NT assumes a THUMB only environment. As such, any address that is detected as residing in an executable section is adjusted to have its bottom bit set to indicate THUMB in case of a mode exchange. Although the testing here seems insufficient (missing the negative cases) the existing test cases for the IMAGE_REL_ARM_{ADDR32,MOV32T} are relevant as they ensure that we do not incorrectly set the bit. llvm-svn: 225104
* ReaderWriter: teach the writer about IMAGE_REL_ARM_BRANCH24TSaleem Abdulrasool2015-01-021-1/+7
| | | | | | | | | | This adds support for IMAGE_REL_ARM_BRANCH24T relocations. Similar to the IMAGE_REL_ARM_BLX32T relocation, this relocation requires munging an instruction. The instruction encoding is quite similar, allowing us to reuse the same munging implementation. This is needed by the entry point stubs for modules provided by MSVCRT. llvm-svn: 225082
* ReaderWriter: teach the writer about IMAGE_REL_ARM_BLX23TSaleem Abdulrasool2015-01-021-0/+20
| | | | | | | | | This adds support for IMAGE_REL_ARM_BLX23T relocations. Similar to the IMAGE_REL_ARM_MOV32T relocation, this relocation requires munging an instruction. This inches us closer to supporting a basic hello world application. llvm-svn: 225081
* ReaderWriter: teach the writer about IMAGE_REL_ARM_MOV32TSaleem Abdulrasool2015-01-021-0/+17
| | | | | | | | | This adds support for the IMAGE_REL_ARM_MOV32T relocation. This is one of the most complicated relocations for the Window on ARM target. It involves re-encoding an instruction to contain an immediate value which is the relocation target. llvm-svn: 225072
* ReaderWriter: teach the writer about IMAGE_REL_ARM_ADDR32Saleem Abdulrasool2015-01-011-4/+25
| | | | | | | | This implements the IMAGE_REL_ARM_ADDR32 relocation. There are still a few more relocation types that need to resolved before lld can even attempt to link a trivial program for Windows on ARM. llvm-svn: 225057
* ReaderWriter: teach PE/COFF backend about ARM NTSaleem Abdulrasool2014-12-311-0/+3
| | | | | | | | | This teaches lld about the ARM NT object types. Add a trivial test to ensure that it can handle ARM NT object file inputs. It is still unable to perform the necessary relocations for ARM NT, but this allows the linker to at least read the objects. llvm-svn: 225052
* [PECOFF] Fix section alignment.Rui Ueyama2014-11-141-12/+31
| | | | | | | | | | | | | | | | | If you have something like __declspec(align(8192)) int foo = 1; in your code, the compiler makes the data to be aligned to 8192-byte boundary, and the linker align the section containing the data to 8192. LLD always aligned the section to 4192. So, as long as alignment requirement is smaller than 4192, it was correct, but for larger requirements, it's wrong. This patch fixes the issue. llvm-svn: 222043
* [PECOFF] Remove dead codeRui Ueyama2014-11-141-4/+0
| | | | | | | | | AddressOfEntryPoint is overridden after we layout all atoms (until then, we don't know the entry point address for obvious reason.) I believe this code is leftover from very early version of the PE/COFF port that we only had an entry function in a test object file. llvm-svn: 222026
* [PECOFF] Add a comment for SECREL relocation.Rui Ueyama2014-11-061-0/+2
| | | | llvm-svn: 221423
* [PECOFF] Fix SECREL relocations.Rui Ueyama2014-11-061-1/+1
| | | | | | | | | | SECREL relocation's value is the offset to the beginning of the section. Because of the off-by-one error, if a SECREL relocation target is at the beginning of a section, it got wrong value. Added a test that would have caught this. llvm-svn: 221420
* PECOFF: Set the AddressOfRelocationTable in the DOS headerDavid Majnemer2014-11-051-0/+1
| | | | | | | | | Many programs, for reasons unknown, really like to look at the AddressOfRelocationTable to determine whether or not they are looking at a bona fide PE file. Without this, programs like the UNIX `file' utility will insist that they are looking at a MS DOS executable. llvm-svn: 221335
* PECOFF: Use the string table for long section names in EXEs/DLLsDavid Majnemer2014-11-041-13/+69
| | | | | | | | | | | | | Normally, PE files have section names of eight characters or less. However, this is problematic for DWARF because DWARF section names are things like .debug_aranges. Instead of truncating the section name, redirect the section name into the string table. Differential Revision: http://reviews.llvm.org/D6104 llvm-svn: 221212
* Fix a leak found by asan.Rafael Espindola2014-11-031-12/+15
| | | | llvm-svn: 221179
* Sort include files according to convention.Shankar Easwaran2014-10-181-3/+0
| | | | llvm-svn: 220131
* [PECOFF] Emit the delay-import tableRui Ueyama2014-10-091-0/+1
| | | | | | | | | | | This is a partial patch to emit the delay-import table. With this, LLD is now able to emit the table that llvm-readobj can read and dump. The table lacks a few fields, such as the address of HMODULE, the import address table, etc. They'll be added in subsequent patches. llvm-svn: 219384
* Use llvm::StringSwitch.Rui Ueyama2014-10-081-19/+16
| | | | llvm-svn: 219341
* PE/COFF: rename applyRelocations* familySaleem Abdulrasool2014-10-071-18/+18
| | | | | | | Use x86 and x64 which is the canonical Microsoft vernacular for the targets. Addresses post-commit review comments from Rui. llvm-svn: 219179
* Do not use llvm_unreachable at reachable code.Rui Ueyama2014-10-071-3/+3
| | | | | | | These lines can be reachable if we give a broken or unsupported input object file. llvm-svn: 219176
* PE/COFF: remove another use of PECOFFLinkingContext::is64bitSaleem Abdulrasool2014-10-051-20/+37
| | | | | | | | | | | | | In order to support more than x86/x86_64, we need to change the behaviour to use the actual machine type rather than checking the bitness and assuming that we are on X86. This replaces the use of is64bit in applyAllRelocations with a check on the machine type. This will enable adding support for handling ARM relocations. Rename the existing applyRelocation methods to be similarly named and to make it clear the types of relocations they will process. llvm-svn: 219088
* PECOFF: loosen another assumption of x86 onlySaleem Abdulrasool2014-09-191-4/+14
| | | | | | | | | | | | Cache the machine type value of the linking context. We need this in order to calculate the virtual address of the atom when resolving function symbols. Windows on ARM must check if the atom is a function and if so, set the Thumb bit for the returned virtual address. Failure to do so will result in an abnormal exit due to a trap caused by invalid instruction decoding. The same information can be used to determine the relocation type that was previously being done via is64 to select between x86 and x86_64. llvm-svn: 218106
* [PECOFF] __tls_used is _tls_used on x64.Rui Ueyama2014-09-191-5/+7
| | | | llvm-svn: 218090
* [PECOFF] Support TLS callbacks.Rui Ueyama2014-09-181-14/+28
| | | | | | | | | | | | | | | | | | | | | | The contents from section .CRT$XLA to .CRT$XLZ is an array of function pointers. They are called by the runtime when a new thread is created or (gracefully) terminated. You can make your own initialization function to be called by that mechanism. All you have to do is: - Define a pointer to a function in a .CRT$XL* section using pragma - Make an external reference to "__tls_used" symbol That technique is used in many projects. This patch is to support that. What this patch does is to set the relative virtual address of "__tls_used" to the PECOFF directory table. __tls_used is actually a struct containing pointers to a symbol in .CRT$XLA and another symbol in .CRT$XLZ. The runtime looks at the directory table, gets the address of the struct, and call the function pointers between XLA and XLZ. llvm-svn: 218007
* [PECOFF] Do r217639 leftover.Rui Ueyama2014-09-111-9/+9
| | | | llvm-svn: 217645
* [PECOFF] Use ulittle32_t::operator+=.Rui Ueyama2014-09-111-15/+9
| | | | llvm-svn: 217639
* [PECOFF] Fix AMD64_REL_[1-5] and AMD64_SECTION relocationsRui Ueyama2014-08-291-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | I hope this is the last fix for x64 relocations as I've wasted a few days on this. This caused a mysterious issue that some C++ programs crash on startup. It was because a null pointer is passed as argv to main. __tmainCRTStartup calls main, but before that it calls all initialization routines between .text$xc_a and .text$xc_z. pre_cpp_init is one of such routines, and it is the one who initializes a heap pointer for argv for later use. That routine was not called for some reason. It turned out that __tmainCRTStartup was skipping a block of code because of the relocation bug. A condition in the function depends on a memory load, and that memory load was referring a wrong location. As a result a jump instruction took the wrong branch, skipping pre_cpp_init and so on. This patch fixes the issue. Also added more tests to fix them once and for all. llvm-svn: 216772
OpenPOWER on IntegriCloud