summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.h
Commit message (Collapse)AuthorAgeFilesLines
* [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
* Adding multiple object support to MCJIT EH frame handlingAndrew Kaylor2013-10-111-3/+7
| | | | llvm-svn: 192504
* Adding multiple GOT handling to RuntimeDyldELFAndrew Kaylor2013-10-051-4/+8
| | | | | | Patch by Ashok Thirumurthi llvm-svn: 192020
* Adding PIC support for ELF on x86_64 platformsAndrew Kaylor2013-08-191-3/+16
| | | | llvm-svn: 188726
* Add EH support to the MCJIT.Rafael Espindola2013-05-051-0/+1
| | | | | | | | | This gets exception handling working on ELF and Macho (x86-64 at least). Other than the EH frame registration, this patch also implements support for GOT relocations which are used to locate the personality function on MachO. llvm-svn: 181167
* AArch64: implement first relocation required for MCJITTim Northover2013-05-041-0/+6
| | | | | | | | | | | R_AARCH64_PCREL32 is present in even trivial .eh_frame sections and so is required to compile any function without the "nounwind" attribute. This change implements very basic infrastructure in the RuntimeDyldELF file and allows (for example) the test-shift.ll MCJIT test to pass on AArch64. llvm-svn: 181131
* [SystemZ] Add MCJIT supportRichard Sandiford2013-05-031-0/+5
| | | | | | | | Another step towards reinstating the SystemZ backend. I'll commit the configure changes separately (TARGET_HAS_JIT etc.), then commit a patch to enable the MCJIT tests on SystemZ. llvm-svn: 181015
* Add getSymbolAlignment to the ObjectFile interface.Rafael Espindola2013-04-291-3/+0
| | | | | | | | | | | | | For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
* Rationalize what is public in RuntimeDyldMachO and RuntimeDyldELF.Rafael Espindola2013-04-291-14/+10
| | | | | | | | The implemented RuntimeDyldImpl interface is public. Everything else is private. Since these classes are not inherited from (yet), there is no need to have protected members. llvm-svn: 180733
* Use a RelocationRef instead of a relocation_iterator.Rafael Espindola2013-04-291-1/+1
| | | | | | No functionality change. llvm-svn: 180723
* Propagate relocation info to resolveRelocation.Rafael Espindola2013-04-291-5/+7
| | | | | | This gets most of the MCJITs tests passing with MachO. llvm-svn: 180716
* Replace ObjRelocationInfo with relocation_iterator.Rafael Espindola2013-04-291-1/+2
| | | | | | | | | | | For MachO we need information that is not represented in ObjRelocationInfo. Instead of copying the bits we think are needed from a relocation_iterator, just pass the relocation_iterator down to the format specific functions. No functionality change yet as we still drop the information once processRelocationRef returns. llvm-svn: 180711
* Change resolveRelocation parameters so the relocations can find placeholder ↵Andrew Kaylor2012-11-021-12/+12
| | | | | | | | values in the original object buffer. Some ELF relocations require adding the a value to the original contents of the object buffer at the specified location. In order to properly handle multiple applications of a relocation, the RuntimeDyld code should be grabbing the original value from the object buffer and writing a new value into the loaded section buffer. This patch changes the parameters passed to resolveRelocations to accommodate this need. llvm-svn: 167304
* Make use of common-symbol alignment info in ELF loader.Tim Northover2012-10-291-1/+13
| | | | | | Patch by Amara Emerson. llvm-svn: 166919
* PowerPC: Initial support for PowerPC64 MCJITAdhemerval Zanella2012-10-251-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds initial support for MCJIT for PPC64-elf-abi. The TOC relocation and ODP handling is implemented. It fixes the following ExecutionEngine testcases: ExecutionEngine/2003-01-04-ArgumentBug.ll ExecutionEngine/2003-01-04-LoopTest.ll ExecutionEngine/2003-01-04-PhiTest.ll ExecutionEngine/2003-01-09-SARTest.ll ExecutionEngine/2003-01-10-FUCOM.ll ExecutionEngine/2003-01-15-AlignmentTest.ll ExecutionEngine/2003-05-11-PHIRegAllocBug.ll ExecutionEngine/2003-06-04-bzip2-bug.ll ExecutionEngine/2003-06-05-PHIBug.ll ExecutionEngine/2003-08-15-AllocaAssertion.ll ExecutionEngine/2003-08-21-EnvironmentTest.ll ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll ExecutionEngine/simplesttest.ll ExecutionEngine/simpletest.ll ExecutionEngine/stubs.ll ExecutionEngine/test-arith.ll ExecutionEngine/test-branch.ll ExecutionEngine/test-call-no-external-funcs.ll ExecutionEngine/test-cast.ll ExecutionEngine/test-common-symbols.ll ExecutionEngine/test-constantexpr.ll ExecutionEngine/test-fp-no-external-funcs.ll ExecutionEngine/test-fp.ll ExecutionEngine/test-global-init-nonzero.ll ExecutionEngine/test-global.ll ExecutionEngine/test-loadstore.ll ExecutionEngine/test-local.ll ExecutionEngine/test-logical.ll ExecutionEngine/test-loop.ll ExecutionEngine/test-phi.ll ExecutionEngine/test-ret.ll ExecutionEngine/test-return.ll ExecutionEngine/test-setcond-fp.ll ExecutionEngine/test-setcond-int.ll ExecutionEngine/test-shift.ll llvm-svn: 166678
* Clean-up of memory buffer and object ownership model in MCJITAndrew Kaylor2012-10-021-6/+3
| | | | llvm-svn: 165053
OpenPOWER on IntegriCloud