summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix some comment typos.Benjamin Kramer2015-08-081-2/+2
| | | | llvm-svn: 244402
* Convert getSymbolSection to return an ErrorOr.Rafael Espindola2015-08-071-4/+4
| | | | | | | This function can actually fail since the symbol contains an index to the section and that can be invalid. llvm-svn: 244375
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-08-051-1/+1
| | | | | | | | | | | deprecated in C++11 LoadedObjectInfo was depending on the implicit copy ctor in the presence of a user-declared dtor. Default (and protect) it in the base class and make the devired classes final to avoid any risk of a public API that would enable slicing. llvm-svn: 244112
* [RuntimeDyld] Adapt PPC64 relocations to PPC32Hal Finkel2015-08-041-0/+23
| | | | | | | | | Begin adapting some of the implemented PPC64 relocations for PPC32 (with a test case). Patch by Pierre-Andre Saulais! llvm-svn: 243991
* [RuntimeDyld] Make LoadedObjectInfo::getLoadedSectionAddress take a SectionRefLang Hames2015-07-281-12/+15
| | | | | | rather than a string section name. llvm-svn: 243456
* [Mips] Add support for MCJIT for MIPS32r6Petar Jovanovic2015-07-061-3/+58
| | | | | | | | | | Add support for resolving MIPS32r6 relocations in MCJIT. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D10687 llvm-svn: 241442
* Return ErrorOr from SymbolRef::getName.Rafael Espindola2015-07-021-2/+6
| | | | | | | | | | | | This function can really fail since the string table offset can be out of bounds. Using ErrorOr makes sure the error is checked. Hopefully a lot of the boilerplate code in tools/* can go away once we have a diagnostic manager in Object. llvm-svn: 241297
* Don't return error_code from a function that doesn't fail.Rafael Espindola2015-06-301-6/+3
| | | | llvm-svn: 241033
* Cleanup getRelocationAddend.Rafael Espindola2015-06-301-7/+5
| | | | | | | | | | | Realistically, this will be returning ErrorOr for some time as refactoring the user code to check once per section will take some time. Given that, use it for checking if a relocation has addend or not. While at it, add ELFRelocationRef to simplify the users. llvm-svn: 241028
* Don't return error_code from function that never fails.Rafael Espindola2015-06-291-4/+2
| | | | llvm-svn: 241021
* Simplify getSymbolType.Rafael Espindola2015-06-261-1/+1
| | | | | | | | This is still a really odd function. Most calls are in object format specific contexts and should probably be replaced with a more direct query, but at least now this is not too obnoxious to use. llvm-svn: 240777
* Make getOther ELF only.Rafael Espindola2015-06-261-3/+2
| | | | | | No other format has this field. llvm-svn: 240774
* [mips64] Emit correct addend for some PC-relative relocationsPetar Jovanovic2015-06-231-1/+1
| | | | | | | | | | | So far, LLVM has not emitted correct addend for N64 and N32 ABI. This patch fixes that. It also removes fixup from MCJIT for R_MIPS_PC16 relocation. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D10565 llvm-svn: 240404
* Improve error handling of getRelocationAddend.Rafael Espindola2015-06-191-10/+12
| | | | | | | | | | | | | | | | | | This patch changes getRelocationAddend to use ErrorOr and considers it an error to try to get the addend of a REL section. If, for example, a x86_64 file has a REL section, that file is corrupted and we should reject it. Using ErrorOr is not ideal since we check the section type once per relocation instead of once per section. Checking once per section would involve getRelocationAddend just asserting and callers checking the section before iterating over the relocations. In any case, this is an improvement and includes a test. llvm-svn: 240176
* fix crashAlexei Starovoitov2015-06-101-1/+2
| | | | | | | | | fix segfault by checking for UnknownArch, since getArchTypePrefix() will return nullptr for UnknownArch. This fixes regression caused by r238424. llvm-svn: 239456
* [Mips64][mcjit] Add R_MIPS_PC32 relocationPetar Jovanovic2015-06-081-0/+5
| | | | | | | | | | This patch adds R_MIPS_PC32 relocation for Mips64. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D10235 llvm-svn: 239301
* Re-commit r238838, r238844 with fix for host/target endian mismatch and ↵Daniel Sanders2015-06-031-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | windows buildbot. The windows buildbot originally failed because the check expressions are evaluated as 64-bit values, even for 32-bit symbols. Fixed this by comparing bottom 32-bits of the expressions. The host/target endian mismatch issue is that it's invalid to read/write target values using a host pointer without taking care of endian differences between the target and host. Most (if not all) instances of reinterpret_cast<uint32_t*>() in the RuntimeDyld are examples of this bug. This has been fixed for Mips using the endian aware read/write functions. The original commits were: r238838: [mips] Add RuntimeDyld tests for currently supported O32 relocations. Reviewers: petarj, vkalintiris Reviewed By: vkalintiris Subscribers: vkalintiris, llvm-commits Differential Revision: http://reviews.llvm.org/D10126 r238844: [mips][mcjit] Add support for R_MIPS_PC32. Summary: This allows us to resolve relocations for DW_EH_PE_pcrel TType encodings in the exception handling LSDA. Also fixed a nearby typo. Reviewers: petarj, vkalintiris Reviewed By: vkalintiris Subscribers: vkalintiris, llvm-commits Differential Revision: http://reviews.llvm.org/D10127 llvm-svn: 238915
* This reverts commit r238838, r238844 and r238888.Rafael Espindola2015-06-031-5/+1
| | | | | | | | Trying to bring back a windows bot: http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/1224/steps/ninja%20check%202/logs/FAIL%3A%20LLVM%3A%3AELF_O32_PIC_relocations.s llvm-svn: 238903
* [mips][mcjit] Add support for R_MIPS_PC32.Daniel Sanders2015-06-021-1/+5
| | | | | | | | | | | | | | | | | | Summary: This allows us to resolve relocations for DW_EH_PE_pcrel TType encodings in the exception handling LSDA. Also fixed a nearby typo. Reviewers: petarj, vkalintiris Reviewed By: vkalintiris Subscribers: vkalintiris, llvm-commits Differential Revision: http://reviews.llvm.org/D10127 llvm-svn: 238844
* Simplify now that we always use an alignment of 2 for ELF files.Rafael Espindola2015-06-021-4/+4
| | | | | | This saves 123144 bytes out of llvm-nm on powerpc64le. llvm-svn: 238824
* [RuntimeDydlELF] Use range-based loop.Davide Italiano2015-06-021-5/+3
| | | | | | | Differential Revision: http://reviews.llvm.org/D10165 Reviewed by: rafael llvm-svn: 238804
* [Mips64] Add support for MCJIT for MIPS64r2 and MIPS64r6Petar Jovanovic2015-05-281-6/+247
| | | | | | | | | | Add support for resolving MIPS64r2 and MIPS64r6 relocations in MCJIT. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D9667 llvm-svn: 238424
* Reapply part of r237975, "Fix Clang -Wmissing-override warning", except for ↵NAKAMURA Takumi2015-05-221-4/+3
| | | | | | DIContext.h, to apease g++-4.7. llvm-svn: 238012
* Revert "Fix Clang -Wmissing-override warning"Tobias Grosser2015-05-221-3/+4
| | | | | | This reverts commit r237975. This seems also to break with gcc 4.7 llvm-svn: 238004
* Fix Clang -Wmissing-override warningDavid Blaikie2015-05-221-4/+3
| | | | | | | & remove the duplication by introducing a CRTP base to implement the clone behavior. llvm-svn: 237975
* Make it easier to use DwarfContext with MCJITKeno Fischer2015-05-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This supersedes http://reviews.llvm.org/D4010, hopefully properly dealing with the JIT case and also adds an actual test case. DwarfContext was basically already usable for the JIT (and back when we were overwriting ELF files it actually worked out of the box by accident), but in order to resolve relocations correctly it needs to know the load address of the section. Rather than trying to get this out of the ObjectFile or requiring the user to create a new ObjectFile just to get some debug info, this adds the capability to pass in that info directly. As part of this I separated out part of the LoadedObjectInfo struct from RuntimeDyld, since it is now required at a higher layer. Reviewers: lhames, echristo Reviewed By: echristo Subscribers: vtjnash, friss, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D6961 llvm-svn: 237961
* [RuntimeDyld] Use isInt to assert that a relocation didn't overflowDavid Majnemer2015-05-151-6/+3
| | | | | | | | | | isInt is a little easier to read, let's use that more consistently. Incidentally, this also silences a warning for shifting a negative number. This fixes PR23532. llvm-svn: 237476
* Reapply [RuntimeDyldELF] Fold Placeholder into AddendKeno Fischer2015-05-011-187/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies r235060 and 235070, which were reverted because of test failures in LLDB. The failure was caused because at moment RuntimeDyld is processing relocations for all sections, irrespective of whether we actually load them into memory or not, but RuntimeDyld was not actually remembering where in memory the unrelocated section is. This commit includes a fix for that issue by remembering that pointer, though the longer term fix should be to stop processing unneeded sections. Original Summary: This allows us to get rid of the original unrelocated object file after we're done processing relocations (but before applying them). MachO and COFF already do not require this (currently we have temporary hacks to prevent ownership from being released, but those are brittle and should be removed soon). The placeholder mechanism allowed the relocation resolver to look at original object file to obtain more information that are required to apply the relocations. This is usually necessary in two cases: - For relocations targetting sub-word memory locations, there may be pieces of the instruction at the target address which we should not override. - Some relocations on some platforms allow an extra addend to be encoded in their immediate fields. The problem is that in the second case the information cannot be recovered after the relocations have been applied once because they will have been overridden. In the first case we also need to be careful to not use any bits that aren't fixed and may have been overriden by applying a first relocation. In the past both have been fixed by just looking at original object file. This patch attempts to recover the information from the first by looking at the relocated object file, while the extra addend in the second case is read upon relocation processing and addend to the regular addend. I have tested this on X86. Other platforms represent my best understanding of how those relocations should work, but I may have missed something because I do not have access to those platforms. We will keep the ugly workarounds in place for a couple of days, so this commit can be reverted if it breaks the bots. Differential Revision: http://reviews.llvm.org/D9028 llvm-svn: 236341
* Revert "[RuntimeDyldELF] Fold Placeholder into Addend"Pavel Labath2015-04-161-170/+187
| | | | | | This reverts commit cbbeac14f0ddca71f6d8ff91cd05522bd23908e5. llvm-svn: 235082
* Revert "[RuntimeDyldELF] Fix missing cases in Placeholder processing"Pavel Labath2015-04-161-3/+1
| | | | | | This reverts commit ec0a34f850eca0d97e0592236e0ac14083aa1c3d. llvm-svn: 235081
* [RuntimeDyldELF] Fix missing cases in Placeholder processingKeno Fischer2015-04-161-1/+3
| | | | | | | Try to appease the build bots. We should write rtdyld test cases for these to make them testible on other platforms. llvm-svn: 235070
* [RuntimeDyldELF] Fold Placeholder into AddendKeno Fischer2015-04-151-187/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This allows us to get rid of the original unrelocated object file after we're done processing relocations (but before applying them). MachO and COFF already do not require this (currently we have temporary hacks to prevent ownership from being released, but those are brittle and should be removed soon). The placeholder mechanism allowed the relocation resolver to look at original object file to obtain more information that are required to apply the relocations. This is usually necessary in two cases: - For relocations targetting sub-word memory locations, there may be pieces of the instruction at the target address which we should not override. - Some relocations on some platforms allow an extra addend to be encoded in their immediate fields. The problem is that in the second case the information cannot be recovered after the relocations have been applied once because they will have been overridden. In the first case we also need to be careful to not use any bits that aren't fixed and may have been overriden by applying a first relocation. In the past both have been fixed by just looking at original object file. This patch attempts to recover the information from the first by looking at the relocated object file, while the extra addend in the second case is read upon relocation processing and addend to the regular addend. I have tested this on X86. Other platforms represent my best understanding of how those relocations should work, but I may have missed something because I do not have access to those platforms. We will keep the ugly workarounds in place for a couple of days, so this commit can be reverted if it breaks the bots. Reviewers: petarj, t.p.northover, lhames Reviewed By: lhames Subscribers: aemerson, llvm-commits Differential Revision: http://reviews.llvm.org/D9028 llvm-svn: 235060
* [RuntimeDyldELF] Improve GOT supportKeno Fischer2015-04-141-102/+65
| | | | | | | | | | | | | | | | | | Summary: This is the first in a series of patches to eventually add support for TLS relocations to RuntimeDyld. This patch resolves an issue in the current GOT handling, where GOT entries would be reused between object files, which leads to the same situation that necessitates the GOT in the first place, i.e. that the 32-bit offset can not cover all of the address space. Thus this patch makes the GOT object-file-local. Unfortunately, this still isn't quite enough, because the MemoryManager does not yet guarantee that sections are allocated sufficiently close to each other, even if they belong to the same object file. To address this concern, this patch also adds a small API abstraction on top of the GOT allocation mechanism that will allow (temporarily, until the MemoryManager is improved) using the stub mechanism instead of allocating a different section. The actual switch from separate section to stub mechanism will be part of a follow-on commit, so that it can be easily reverted independently at the appropriate time. Test Plan: Includes a test case where the GOT of two object files is artificially forced to be apart by several GB. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8813 llvm-svn: 234839
* [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames2015-03-301-27/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MCJIT. This patch decouples the two responsibilities of the RTDyldMemoryManager class, memory management and symbol resolution, into two new classes: RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver. The symbol resolution interface is modified slightly, from: uint64_t getSymbolAddress(const std::string &Name); to: RuntimeDyld::SymbolInfo findSymbol(const std::string &Name); The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld and others to reason about non-strong/non-exported symbols. The memory management interface removes the following method: void notifyObjectLoaded(ExecutionEngine *EE, const object::ObjectFile &) {} as it is not related to memory management. (Note: Backwards compatibility *is* maintained for this method in MCJIT and OrcMCJITReplacement, see below). The RTDyldMemoryManager class remains in-tree for backwards compatibility. It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which just subclasses RuntimeDyld::MemoryManager and reintroduces the notifyObjectLoaded method for backwards compatibility). The EngineBuilder class retains the existing method: EngineBuilder& setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm); and includes two new methods: EngineBuilder& setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM); EngineBuilder& setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR); Clients should use EITHER: A single call to setMCJITMemoryManager with an RTDyldMemoryManager. OR (exclusive) One call each to each of setMemoryManager and setSymbolResolver. This patch should be fully compatible with existing uses of RTDyldMemoryManager. If it is not it should be considered a bug, and the patch either fixed or reverted. If clients find the new API to be an improvement the goal will be to deprecate and eventually remove the RTDyldMemoryManager class in favor of the new classes. llvm-svn: 233509
* Simplify expressions involving boolean constants with clang-tidyDavid Blaikie2015-03-091-1/+1
| | | | | | | | Patch by Richard (legalize at xmission dot com). Differential Revision: http://reviews.llvm.org/D8154 llvm-svn: 231617
* Revert r227247 and r227228: "Add weak symbol support to RuntimeDyld".Lang Hames2015-01-281-1/+0
| | | | | | | | | This has wider implications than I expected when I reviewed the patch: It can cause JIT crashes where clients have used the default value for AbortOnFailure during symbol lookup. I'm currently investigating alternative approaches and I hope to have this back in tree soon. llvm-svn: 227287
* [ExecutionEngine] Add weak symbol support to RuntimeDyldKeno Fischer2015-01-271-0/+1
| | | | | | | | | | | Support weak symbols by first looking up if there is an externally visible symbol we can find, and only if that fails using the one in the object file we're loading. Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6950 llvm-svn: 227228
* [RuntimeDyld] Track symbol visibility in RuntimeDyld.Lang Hames2015-01-161-4/+5
| | | | | | | | | | | | | | | | | | | RuntimeDyld symbol info previously consisted of just a Section/Offset pair. This patch replaces that pair type with a SymbolInfo class that also tracks symbol visibility. A new method, RuntimeDyld::getExportedSymbolLoadAddress, is introduced which only returns a non-zero result for exported symbols. For non-exported or non-existant symbols this method will return zero. The RuntimeDyld::getSymbolAddress method retains its current behavior, returning non-zero results for all symbols regardless of visibility. No in-tree clients of RuntimeDyld are changed. The newly introduced functionality will be used by the Orc APIs. No test case: Since this patch doesn't modify the behavior for any in-tree clients we don't have a good tool to test this with yet. Once Orc is in we can use it to write regression tests that test these changes. llvm-svn: 226341
* [MCJIT] Remove the local symbol table from RuntimeDlyd - it's not needed.Lang Hames2014-11-271-48/+41
| | | | | | | | All symbols have to be stored in the global symbol to enable cross-rtdyld-instance linking, so the local symbol table content is redundant. llvm-svn: 222867
* [MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.Lang Hames2014-11-261-151/+109
| | | | llvm-svn: 222840
* Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman2014-11-261-109/+151
| | | | | | http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/11753 llvm-svn: 222833
* [MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.Lang Hames2014-11-261-151/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, when loading an object file, RuntimeDyld (1) took ownership of the ObjectFile instance (and associated MemoryBuffer), (2) potentially modified the object in-place, and (3) returned an ObjectImage that managed ownership of the now-modified object and provided some convenience methods. This scheme accreted over several years as features were tacked on to RuntimeDyld, and was both unintuitive and unsafe (See e.g. http://llvm.org/PR20722). This patch fixes the issue by removing all ownership and in-place modification of object files from RuntimeDyld. Existing behavior, including debugger registration, is preserved. Noteworthy changes include: (1) ObjectFile instances are now passed to RuntimeDyld by const-ref. (2) The ObjectImage and ObjectBuffer classes have been removed entirely, they existed to model ownership within RuntimeDyld, and so are no longer needed. (3) RuntimeDyld::loadObject now returns an instance of a new class, RuntimeDyld::LoadedObjectInfo, which can be used to construct a modified object suitable for registration with the debugger, following the existing debugger registration scheme. (4) The JITRegistrar class has been removed, and the GDBRegistrar class has been re-written as a JITEventListener. This should fix http://llvm.org/PR20722 . llvm-svn: 222810
* Remove bogus std::error_code returns form SectionRef.Rafael Espindola2014-10-081-5/+2
| | | | | | | | | | | | | | There are two methods in SectionRef that can fail: * getName: The index into the string table can be invalid. * getContents: The section might point to invalid contents. Every other method will always succeed and returning and std::error_code just complicates the code. For example, a section can have an invalid alignment, but if we are able to get to the section structure at all and create a SectionRef, we will always be able to read that invalid alignment. llvm-svn: 219314
* [MCJIT] Revert partial RuntimeDyldELF cleanup that was prematurely committed inLang Hames2014-09-071-3/+3
| | | | | | r217328. llvm-svn: 217329
* [MCJIT] Rewrite RuntimeDyldMachO and its derived classes to use the 'Offset'Lang Hames2014-09-071-3/+3
| | | | | | | | | | field of RelocationValueRef, rather than the 'Addend' field. This is consistent with RuntimeDyldELF's use of RelocationValueRef, and more consistent with the semantics of the data being stored (the offset from the start of a section or symbol). llvm-svn: 217328
* unique_ptrify a bunch of stuff through RuntimeDyld::loadObjectDavid Blaikie2014-09-031-20/+25
| | | | llvm-svn: 217065
* Fix unaligned reads/writes in X86JIT and RuntimeDyldELF.Alexey Samsonov2014-08-271-26/+22
| | | | | | | | | | | | | | | | Summary: Introduce support::ulittleX_t::ref type to Support/Endian.h and use it in x86 JIT to enforce correct endianness and fix unaligned accesses. Test Plan: regression test suite Reviewers: lhames Subscribers: ributzka, llvm-commits Differential Revision: http://reviews.llvm.org/D5011 llvm-svn: 216631
* [MCJIT][SystemZ] Use a simpler expression for indirect relocation offsets.Lang Hames2014-08-251-1/+1
| | | | | | | | The expressions 'Reloc.Addend - Addend' and 'Reloc.Offset' should always be equal in this context. The latter is prefered - we want to remove the RelocationValueRef::Addend field in the future. llvm-svn: 216418
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-21/+18
| | | | | | | | | | | | | | | | | | | | | | | | | Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
* Use copy initialization to initialize std::unique_ptr.Rafael Espindola2014-08-171-1/+1
| | | | | | Thanks to David Blaikie for the suggestion. llvm-svn: 215867
OpenPOWER on IntegriCloud