summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h
Commit message (Collapse)AuthorAgeFilesLines
* Simplify decoupling between RuntimeDyld/RuntimeDyldChecker, add 'got_addr' util.Lang Hames2019-04-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This patch reduces the number of functions in the interface between RuntimeDyld and RuntimeDyldChecker by combining "GetXAddress" and "GetXContent" functions into "GetXInfo" functions that return a struct describing both the address and content. The GetStubOffset function is also replaced with a pair of utilities, GetStubInfo and GetGOTInfo, that fit the new scheme. For RuntimeDyld both of these functions will return the same result, but for the new JITLink linker (https://reviews.llvm.org/D58704) these will provide the addresses of PLT stubs and GOT entries respectively. For JITLink's use, a 'got_addr' utility has been added to the rtdyld-check language, and the syntax of 'got_addr' and 'stub_addr' has been changed: both functions now take two arguments, a 'stub container name' and a target symbol name. For llvm-rtdyld/RuntimeDyld the stub container name is the object file name and section name, separated by a slash. E.g.: rtdyld-check: *{8}(stub_addr(foo.o/__text, y)) = y For the upcoming llvm-jitlink utility, which creates stubs on a per-file basis rather than a per-section basis, the container name is just the file name. E.g.: jitlink-check: *{8}(got_addr(foo.o, y)) = y llvm-svn: 358295
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in RuntimeDyld.Nitesh Jain2017-10-221-1/+3
| | | | | | | | | | Reviewers: sdardis Subscribers: jaydeep, bhushan, llvm-commits Differential Revision: https://reviews.llvm.org/D38314 llvm-svn: 316287
* Revert [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in ↵Sagar Thakur2017-06-221-3/+1
| | | | | | | | RuntimeDyld Reverting due to build bot failures llvm-svn: 306000
* [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in RuntimeDyldSagar Thakur2017-06-221-1/+3
| | | | | | | | | After the N64 static relocation model support was added to llvm it is required to add its support in RuntimeDyld also because lldb uses ExecutionEngine for evaluating expressions. Reviewed by sdardis Differential: D31649 llvm-svn: 305997
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-091-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames. RuntimeDyld was previously responsible for tracking allocated EH frames, but it makes more sense to have the RuntimeDyld::MemoryManager track them (since the frames are allocated through the memory manager, and written to memory owned by the memory manager). This patch moves the frame tracking into RTDyldMemoryManager, and changes the deregisterFrames method on RuntimeDyld::MemoryManager from: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size); to: void deregisterEHFrames(); Separating this responsibility will allow ORC to continue to throw the RuntimeDyld instances away post-link (saving a few dozen bytes per lazy function) while properly deregistering frames when modules are unloaded. This patch also updates ORC to call deregisterEHFrames when modules are unloaded. This fixes a bug where an exception that tears down the JIT can then unwind through dangling EH frames that have been deallocated but not deregistered, resulting in UB. For people using SectionMemoryManager this should be pretty much a no-op. For people with custom allocators that override registerEHFrames/deregisterEHFrames, you will now be responsible for tracking allocated EH frames. Reviewed in https://reviews.llvm.org/D32829 llvm-svn: 302589
* [bpf] add relocation supportAlexei Starovoitov2017-05-031-0/+3
| | | | | | | | | | . there should be no runtime relocation inside the bpf function. . relocation supported here mostly for debugging. . a test case is added. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> llvm-svn: 302055
* RuntimeDyldELF/AArch64: Implement basic GOT supportEugene Leviant2017-02-061-6/+15
| | | | | | | | | This patch implements two GOT relocations: R_AARCH64_ADR_GOT_PAGE and R_AARCH64_LD64_GOT_LO12_NC Differential revision: https://reviews.llvm.org/D28571 llvm-svn: 294191
* RuntimeDyldELF: don't create thunk if not neededEugene Leviant2017-01-091-0/+3
| | | | | | | | | | | | | This patch doesn't create thunk for branch operation when following conditions are met: - Architecture is AArch64 - Relocation target is in the same object file - Relocation target is close enough to be encoded in immediate offset In such case we branch directly to the target instead of branching to thunk Differential revision: https://reviews.llvm.org/D28108 llvm-svn: 291431
* [mips][rtdyld] Move MIPS relocation resolution to a subclass and implement ↵Simon Dardis2016-12-131-21/+8
| | | | | | | | | | | | | | | N32 relocations N32 relocations are only correct for individual relocations at the moment. Support for relocation composition will follow in a later patch. Patch By: Daniel Sanders Reviwers: vkalintiris, atanasyan Differential Revision: https://reviews.llvm.org/D27467 llvm-svn: 289532
* [mips][rtdyld] Merge code to write relocated values to the section. NFCSimon Dardis2016-12-071-2/+4
| | | | | | | | | | | | Preparation work for implementing N32 support. Patch By: Daniel Sanders Reviewers: vkalintiris, atanasyan Differential Revision: https://reviews.llvm.org/D27460 llvm-svn: 288900
* [mips][mcjit] Add the majority of N32 support.Simon Dardis2016-10-201-3/+6
| | | | | | | | | The missing piece is relocation composition for %hi(%neg(%gp_rel(x))) and similar. Patch by: Daniel Sanders llvm-svn: 284724
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-1/+1
| | | | | | | | | | | | | | | | This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
* Prune RelocVisitor.h include to avoid including COFF.h from MCJIT.hReid Kleckner2016-07-061-0/+3
| | | | | | | This helps to mitigate the conflict between COFF.h and winnt.h, which is PR28399. llvm-svn: 274637
* [RuntimeDyld] Plumb Error/Expected through the internals of RuntimeDyld.Lang Hames2016-04-271-9/+9
| | | | | | | | | | | | | Also replaces a number of calls to report_fatal_error with Error returns. The plumbing will make it easier to return errors originating in libObject. Replacing report_fatal_errors with Error returns will give JIT clients the opportunity to recover gracefully when the JIT is unable to produce/relocate code, as well as providing meaningful error messages that can be used to file bug reports. llvm-svn: 267776
* [RuntimeDyld] Don't allocate unnecessary stub buffer spaceSanjoy Das2015-11-231-0/+2
| | | | | | | | | | | | | | Summary: For relocation types that are known to not require stub functions, there is no need to allocate extra space for the stub functions. Reviewers: lhames, reames, maksfb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14676 llvm-svn: 253920
* [mips][mcjit] Calculate correct addend for HI16 and PCHI16 relocPetar Jovanovic2015-08-131-0/+8
| | | | | | | | | | | Previously, for O32 ABI we did not calculate correct addend for R_MIPS_HI16 and R_MIPS_PCHI16 relocations. This patch fixes that. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D11186 llvm-svn: 244897
* [RuntimeDyld] Adapt PPC64 relocations to PPC32Hal Finkel2015-08-041-0/+3
| | | | | | | | | Begin adapting some of the implemented PPC64 relocations for PPC32 (with a test case). Patch by Pierre-Andre Saulais! llvm-svn: 243991
* Improve error handling of getRelocationAddend.Rafael Espindola2015-06-191-2/+2
| | | | | | | | | | | | | | | | | | 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
* [Mips64] Add support for MCJIT for MIPS64r2 and MIPS64r6Petar Jovanovic2015-05-281-2/+23
| | | | | | | | | | 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 [RuntimeDyldELF] Fold Placeholder into AddendKeno Fischer2015-05-011-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-7/+0
| | | | | | This reverts commit cbbeac14f0ddca71f6d8ff91cd05522bd23908e5. llvm-svn: 235082
* [RuntimeDyldELF] Fold Placeholder into AddendKeno Fischer2015-04-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-7/+23
| | | | | | | | | | | | | | | | | | 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
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-1/+1
| | | | | | | | | | | | | | The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
* [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames2015-03-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ExecutionEngine: Preliminary support for dynamically loadable coff objectsDavid Majnemer2015-03-071-10/+0
| | | | | | | | | | Provide basic support for dynamically loadable coff objects. Only handles a subset of x64 currently. Patch by Andy Ayers! Differential Revision: http://reviews.llvm.org/D7793 llvm-svn: 231574
* [MCJIT] Remove the local symbol table from RuntimeDlyd - it's not needed.Lang Hames2014-11-271-1/+1
| | | | | | | | 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-12/+15
| | | | llvm-svn: 222840
* Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman2014-11-261-15/+12
| | | | | | 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-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* unique_ptrify a bunch of stuff through RuntimeDyld::loadObjectDavid Blaikie2014-09-031-1/+2
| | | | llvm-svn: 217065
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* AArch64: remove arm64 triple enumerator.Tim Northover2014-07-231-2/+1
| | | | | | | | | | | | Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
* [RuntimeDyld, PowerPC] Fix/improve handling of TOC relocationsUlrich Weigand2014-06-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current PPC64 RuntimeDyld code to handle TOC relocations has two problems: - With recent linkers, in addition to the relocations that implicitly refer to the TOC base (R_PPC64_TOC*), you can now also use the .TOC. magic symbol with any other relocation to refer to the TOC base explicitly. This isn't currently used much in ELFv1 code (although it could be), but it is essential in ELFv2 code. - In a complex JIT environment with multiple modules, each module may have its own .toc section, and TOC relocations in one module must refer to *its own* TOC section. The current findPPC64TOC implementation does not correctly implement this; in fact, it will always return the address of the first TOC section it finds anywhere. (Note that at the time findPPC64TOC is called, we don't even *know* which module the relocation originally resided in, so it is not even possible to fix this routine as-is.) This commit fixes both problems by handling TOC relocations earlier, in processRelocationRef. To do this, I've removed the findPPC64TOC routine and replaced it by a new routine findPPC64TOCSection, which works analogously to findOPDEntrySection in scanning the sections of the ObjImage provided by its caller, processRelocationRef. This solves the issue of finding the correct TOC section associated with the current module. This makes it straightforward to implement both R_PPC64_TOC relocations, and relocations explicitly refering to the .TOC. symbol, directly in processRelocationRef. There is now a new problem in implementing the R_PPC64_TOC16* relocations, because those can now in theory involve *three* different sections: the relocation may be applied in section A, refer explicitly to a symbol in section B, and refer implicitly to the TOC section C. The final processing of the relocation thus may only happen after all three of these sections have been assigned final addresses. There is currently no obvious means to implement this in its general form with the common-code RuntimeDyld infrastructure. Fortunately, ppc64 code usually makes no use of this most general form; in fact, TOC16 relocations are only ever generated by LLVM for symbols residing themselves in the TOC, which means "section B" == "section C" in the above terminology. This special case can easily be handled with the current infrastructure, and that is what this patch does. [ Unhandled cases result in an explicit error, unlike the current code which silently returns the wrong TOC base address ... ] This patch makes the JIT work on both BE and LE (ELFv2 requires additional patches, of course), and allowed me to successfully run complex JIT scenarios (via mesa/llvmpipe). Reviewed by Hal Finkel. llvm-svn: 211885
* Remove all uses of 'using std::error_code' from headers.Rafael Espindola2014-06-131-3/+1
| | | | llvm-svn: 210866
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-121-0/+1
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* [RuntimeDyld] Add support for MachO __jump_table and __pointers sections, andLang Hames2014-05-121-1/+2
| | | | | | | | | | | SECTDIFF relocations on 32-bit x86. This fixes several of the MCJIT regression test failures that show up on 32-bit builds. <rdar://problem/16886294> llvm-svn: 208635
* [ARM64] Try and make the ELF MCJIT *slightly* less broken for ARM64.James Molloy2014-04-301-1/+2
| | | | | | | | | A bunch of switch cases were missing, not just for ARM64 but also for AArch64_BE. I've fixed all those, but there's zero testing as ExecutionEngine tests are disabled when crosscompiling and I don't have a native platform available to test on. llvm-svn: 207626
* PR19553: Memory leak in RuntimeDyldELF::createObjectImageFromFileDavid Blaikie2014-04-291-1/+1
| | | | | | | | | | | | | | | | This starts in MCJIT::getSymbolAddress where the unique_ptr<object::Binary> is release()d and (after a cast) passed to a single caller, MCJIT::addObjectFile. addObjectFile calls RuntimeDyld::loadObject. RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile And the pointer is never owned at this point. I say this point, because the alternative codepath, RuntimeDyldMachO::createObjectFile certainly does take ownership, so this seemed like a good hint that this was a/the right place to take ownership. llvm-svn: 207580
* [RuntimeDyld] clang-format files.Juergen Ributzka2014-03-211-57/+31
| | | | llvm-svn: 204507
* [RuntimeDyld] Allow processRelocationRef to process more than one relocation ↵Juergen Ributzka2014-03-211-4/+4
| | | | | | | | | | | | | entry at a time. Some targets require more than one relocation entry to perform a relocation. This change allows processRelocationRef to process more than one relocation entry at a time by passing the relocation iterator itself instead of just the relocation entry. Related to <rdar://problem/16199095> llvm-svn: 204439
* Make createObjectImage and createObjectImageFromFile static methods on theLang Hames2014-03-081-2/+3
| | | | | | | | relevant subclasses of RuntimeDyldImpl. This allows construction of RuntimeDyldImpl instances to be deferred until after the target architecture is known. llvm-svn: 203352
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-081-17/+15
| | | | | | class. llvm-svn: 203344
* Fix known typosAlp Toker2014-01-241-1/+1
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
* Re-apply r196639: Add support for archives and object file caching under MCJIT.Lang Hames2014-01-081-0/+2
| | | | | | | | | I believe the bot failures on linux systems were due to overestimating the alignment of object-files within archives, which are only guaranteed to be two-byte aligned. I have reduced the alignment in RuntimeDyldELF::createObjectImageFromFile accordingly. llvm-svn: 198737
* Revert r196639 while I investigate a bot failure.Lang Hames2013-12-071-2/+0
| | | | llvm-svn: 196641
* Add support for archives and object file caching under MCJIT.Lang Hames2013-12-071-0/+2
| | | | | | Patch by Andy Kaylor, with minor edits to resolve merge conflicts. llvm-svn: 196639
* Adding support for deregistering EH frames with MCJIT.Andrew Kaylor2013-10-161-0/+2
| | | | | | Patch by Yaron Keren llvm-svn: 192753
* Separating ELF and MachO stub info functions for RuntimeDyldAndrew Kaylor2013-10-151-0/+24
| | | | llvm-svn: 192737
OpenPOWER on IntegriCloud