summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/PECOFF
Commit message (Collapse)AuthorAgeFilesLines
...
* PE/COFF: add support to import functions in ARM NTSaleem Abdulrasool2015-01-081-7/+46
| | | | | | | | | | This is necessary to support linking a basic program which references symbols outside of the module itself. Add the import thunk for ARM NT style imports. This allows us to create the reference. However, it is still insufficient to generate executables that will run due to base relocations not being emitted for the import. llvm-svn: 225428
* PE/COFF: teach ARMNT backend about ADDR32NB for exportsSaleem Abdulrasool2015-01-072-0/+7
| | | | | | | | | 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-312-0/+6
| | | | | | | | | 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
* Make File always take the ownership of a MemoryBuffer.Rui Ueyama2014-12-122-2/+2
| | | | | | | | | | | | | | The documentation of parseFile() said that "the resulting File object may take ownership of the MemoryBuffer." So, whether or not the ownership of a MemoryBuffer would be taken was not clear. A FileNode (a subclass of InputElement, which is being deprecated) keeps the ownership if a File doesn't take it. This patch makes File always take the ownership of a buffer. Buffers lifespan is not always the same as File instances. Files are able to deallocate buffers after parsing the contents. llvm-svn: 224113
* Separate file parsing from File's constructors.Rui Ueyama2014-12-122-191/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a second patch for InputGraph cleanup. Sorry about the size of the patch, but what I did in this patch is basically moving code from constructor to a new method, parse(), so the amount of new code is small. This has no change in functionality. We've discussed the issue that we have too many classes to represent a concept of "file". We have File subclasses that represent files read from disk. In addition to that, we have bunch of InputElement subclasses (that are part of InputGraph) that represent command line arguments for input file names. InputElement is a wrapper for File. InputElement has parseFile method. The method instantiates a File. The File's constructor reads a file from disk and parses that. Because parseFile method is called from multiple worker threads, file parsing is processed in parallel. In other words, one reason why we needed the wrapper classes is because a File would start reading a file as soon as it is instantiated. So, the reason why we have too many classes here is at least partly because of the design flaw of File class. Just like threads in a good threading library, we need to separate instantiation from "start" method, so that we can instantiate File objects when we need them (which should be very fast because it involves only one mmap() and no real file IO) and use them directly instead of the wrapper classes. Later, we call parse() on each file in parallel to let them do actual file IO. In this design, we can eliminate a reason to have the wrapper classes. In order to minimize the size of the patch, I didn't go so far as to replace the wrapper classes with File classes. The wrapper classes are still there. In this patch, we call parse() immediately after instantiating a File, so this really has no change in functionality. Eventually the call of parse() should be moved to Driver::link(). That'll be done in another patch. llvm-svn: 224102
* Re-commit r223330: Rewrite InputGraph's GroupRui Ueyama2014-12-101-1/+18
| | | | llvm-svn: 223867
* [PECOFF] Fix exported symbols in an import library.Rui Ueyama2014-12-051-0/+2
| | | | | | | | | | | | | | | | | Looks like if you have symbol foo in a module-definition file (.def file), and if the actual symbol name to match that export description is _foo@x (where x is an integer), the exported symbol name becomes this. - foo in the .dll file - foo@x in the .lib file I have checked in a few fixes recently for exported symbol name mangling. I haven't found a simple rule that governs all the mangling rules. There may not ever exist. For now, this is a patch to improve .lib file compatibility. llvm-svn: 223524
* Remove extra semicolon.Rui Ueyama2014-12-041-1/+1
| | | | llvm-svn: 223411
* Revert "Rewrite InputGraph's Group"Rui Ueyama2014-12-041-18/+1
| | | | | | | | This reverts commit r223330 because it broke Darwin and ELF linkers in a way that we couldn't have caught with the existing test cases. llvm-svn: 223373
* [PECOFF] Improve /export compatibility.Rui Ueyama2014-12-042-29/+46
| | | | | | | | | | | | | | | | | | | | | Looks like the rule of /export is more complicated than I was thinking. If /export:foo, for example, is given, and if the actual symbol name in an object file is _foo@<number>, we need to export that symbol as foo, not as the mangled name. If only /export:_foo@<number> is given, the symbol is exported as _foo@<number>. If both /export:foo and /export:_foo@<number> are given, they are considered as duplicates, and the linker needs to choose the unmangled name. The basic idea seems that the linker needs to export a symbol with the same name as given as /export. We exported mangled symbols. This patch fixes that issue. llvm-svn: 223341
* Rewrite InputGraph's GroupRui Ueyama2014-12-041-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The aim of this patch is to reduce the excessive abstraction from the InputGraph. We found that even a simple thing, such as sorting input files (Mach-O) or adding a new file to the input file list (PE/COFF), is nearly impossible with the InputGraph abstraction, because it hides too much information behind it. As a result, we invented complex interactions between components (e.g. notifyProgress() mechanism) and tricky code to work around that limitation. There were many occasions that we needed to write awkward code. This patch is a first step to make it cleaner. As a first step, this removes Group class from the InputGraph. The grouping feature is now directly handled by the Resolver. notifyProgress is removed since we no longer need that. I could have cleaned it up even more, but in order to keep the patch minimum, I focused on Group. SimpleFileNode class, a container of File objects, is now limited to have only one File. We shold have done this earlier. We used to allow putting multiple File objects to FileNode. Although SimpleFileNode usually has only one file, the Driver class actually used that capability. I modified the Driver class a bit, so that one FileNode is created for each input File. We should now probably remove SimpleFileNode and directly store File objects to the InputGraph in some way, because a container that can contain only one object is useless. This is a TODO. Mach-O input files are now sorted before they are passe to the Resolver. DarwinInputGraph class is no longer needed, so removed. PECOFF still has hacky code to add a new file to the input file list. This will be cleaned up in another patch. llvm-svn: 223330
* [PECOFF] Improve compatibility of /export option.Rui Ueyama2014-12-041-0/+10
| | | | llvm-svn: 223326
* [PECOFF] Fix a bug in /export option handler.Rui Ueyama2014-12-031-7/+10
| | | | | | | | | | | | | | | | | | | /export option can be given multiple times to specify multiple symbols to be exported. /export accepts both decorated and undecorated name. If you give both undecorated and decorated name of the same symbol to /export, they are resolved to the same symbol. In this case, we need to de-duplicate the exported names, so that we don't have duplicated items in the export symbol table in a DLL. We remove duplicate items from a vector. The bug was there. Because we had pointers pointing to elements of the vector, after an item is removed, they would point wrong elements. This patch is to remove these pointers. Added a test for that case. llvm-svn: 223200
* Use SafelyCloseFileDescriptor instead of close.Rui Ueyama2014-11-261-7/+2
| | | | | | | | Opening a file using openFileForWrite and closing it using close was asymmetric. It also had a subtle portability problem (details are described in the commit message for r219189). llvm-svn: 222802
* [PECOFF] Properly close a file descriptor.Rui Ueyama2014-11-261-0/+7
| | | | | | | | This was basically benign resource leak on Unix, but on Windows it could cause builds to fail because opened file descriptor prevents other processes from moving or removing the file. llvm-svn: 222799
* [PECOFF] Create an empty PDB file if debug option is enabled.Rui Ueyama2014-11-252-3/+57
| | | | | | | | | | | | | | | | There are many build files in the wild that depend on the fact that link.exe produces a PDB file if /DEBUG option is given. They fail if the file is not created. This patch is to make LLD create an empty (dummy) file to satisfy such build targets. This doesn't do anything other than "touching" the file. If a target depends on the content of the PDB file, this workaround is no help, of course. Otherwise this patch should help build some stuff. llvm-svn: 222773
* [PECOFF] Sort export table properly.Rui Ueyama2014-11-201-4/+5
| | | | | | | | | | | | | | Export table entries need to be sorted in ASCII-betical order, so that the loader can find an entry for a function by binary search. We sorted the entries by its mangled names. That can be different from their exported names. As a result, LLD produces incorrect export table, from which the loader complains that a function that actually exists in a DLL cannot be found. This patch fixes that issue. llvm-svn: 222452
* [PECOFF] Fix 32-bit delay-import table.Rui Ueyama2014-11-171-1/+1
| | | | llvm-svn: 222116
* [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
* Follow-up to r221913. Fix some -Wcast-qual warning reasons.Simon Atanasyan2014-11-143-4/+5
| | | | llvm-svn: 221974
* [PECOFF] Fix delay-import address table contents.Rui Ueyama2014-11-132-3/+9
| | | | | | | | | | | Each entry in the delay-import address table had a wrong alignment requirement if 32 bit. As a result it got wrong delay-import table. Because llvm-readobj doesn't print out that field, we don't have a test for that. I'll submit a test that would catch this bug after improving llvm-readobj. llvm-svn: 221853
* [PECOFF] Improve subsystem inferenceRui Ueyama2014-11-063-15/+72
| | | | | | | | | | | | | | | | | | | | | | | | | If /subsystem option is not given, the linker needs to infer the subsystem based on the entry point symbol. If it fails to infer that, the linker should error out on it. LLD was almost correct, but it would fail to infer the subsystem if the entry point is specified with /entry. This is because the subsystem inference was coupled with the entry point function searching (if no entry point name is specified, the linker needs to find the right entry name). This patch makes the subsystem inference an independent pass to fix the issue. Now, as long as an entry point function is defined, LLD can infer the subsystem no matter how it resolved the entry point. I don't think scanning all the defined symbols is fast, although it shouldn't be that slow. The file class there does not provide any easy way to find an atom by name, so this is what we can do at this moment. I'd like to revisit this later to make it more efficient. llvm-svn: 221499
* [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] Do not skip COMDAT section symbols.Rui Ueyama2014-11-051-11/+0
| | | | | | | | | LLD skipped COMDAT section symbols when reading them because I thought we don't want to have symbols with the same name. But they are actually needed because relocations may refer to the section symbols. So we shoulnd't skip them. llvm-svn: 221329
* [PECOFF] Fix symbols in module-definition file.Rui Ueyama2014-11-041-1/+9
| | | | llvm-svn: 221303
* Use llvm::sys::findProgramByName. NFC.Rafael Espindola2014-11-041-19/+22
| | | | llvm-svn: 221257
* 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
* Fix warnings about missing override.Rafael Espindola2014-11-031-1/+0
| | | | llvm-svn: 221165
* [PECOFF] Do not write duplicate directives to .def file.Rui Ueyama2014-10-221-3/+22
| | | | | | | | | | | This is a follow-up patch for r220333. r220333 renames exported symbols. That raised another issue; if we have both decorated and undecorated names for the same symbol, we'll end up have two duplicate exported symbol entries. This is a fix for that issue by removing duplciate entries. llvm-svn: 220350
* [PECOFF] Fix exported symbol in the import libraryRui Ueyama2014-10-212-2/+3
| | | | | | | | | | | | | | | | | | | | | | There are two ways to specify a symbol to be exported in the module definition file. 1) EXPORT <external name> = <symbol> 2) EXPORT <symbol> In (1), you give both external name and internal name. In that case, the linker tries to find a symbol using the internal name, and write that address to the export table with the external name. Thus, from the outer world, the symbol seems to be exported as the external name. In (2), internal name is basically the same as the external name with an exception: if you give an undecorated symbol to the EXPORT directive, and if the linker finds a decorated symbol, the external name for the symbol will become the decorated symbol. LLD didn't implement that exception correctly. This patch fixes that. llvm-svn: 220333
* [PECOFF] Look for decorated entry symbol name.Rui Ueyama2014-10-211-1/+5
| | | | | | | Entry symbol name can be decorated. When we look for _WinMain, we also have to look for _WinMain@16. llvm-svn: 220259
* Sort include files according to convention.Shankar Easwaran2014-10-1812-22/+0
| | | | llvm-svn: 220131
* [PECOFF] Emit x64 delay-import wrapper functionRui Ueyama2014-10-174-10/+71
| | | | | | | | | | | Previously we supported x86 only. This patch is to support x64. The array of pointers to delay-loaded functions points the DLL delay loading function at start-up. When a function is called for the first time, the delay loading function gets called and then rewrite the function pointer array. llvm-svn: 220096
* [CMake] lld: Introduce ${cmake_2_8_12_INTERFACE} onto each ↵NAKAMURA Takumi2014-10-171-1/+1
| | | | | | | target_link_libraries. [PR20254] FIXME: Dependencies should be reorganized. llvm-svn: 220000
* [PECOFF] Support delay-load import table for x86Rui Ueyama2014-10-164-8/+111
| | | | | | | | | | This patch creates the import address table and sets its address to the delay-load import table. This also creates wrapper functions for __delayLoadHelper2. x86 only for now. llvm-svn: 219948
* Use llvm::make_unique.Rui Ueyama2014-10-143-14/+12
| | | | llvm-svn: 219709
* [PECOFF] Refactor _imp_ symbol generator.Rui Ueyama2014-10-091-21/+28
| | | | | | | | We are going to have another type of jump table for the delay-load import table. In order to prepare for that, we want to factor out the function handling the jump table. No functionality change. llvm-svn: 219446
* [PECOFF] Remove another use of is64 to support non-Intel architectureRui Ueyama2014-10-091-19/+30
| | | | llvm-svn: 219438
* [PECOFF] Emit ModuleHandle field in delay-import table.Rui Ueyama2014-10-092-3/+22
| | | | | | | | Previously the field was not set. The field should be pointing to a placeholder where the DLL delay-loader writes the base address of a DLL. llvm-svn: 219415
* [PECOFF] Emit the delay-import tableRui Ueyama2014-10-093-3/+89
| | | | | | | | | | | 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
OpenPOWER on IntegriCloud