summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
...
* [RuntimeDyld] Add a framework for testing relocation logic in RuntimeDyld.Lang Hames2014-06-273-2/+654
| | | | | | | | | | | | | | | | | | | | This patch adds a "-verify" mode to the llvm-rtdyld utility. In verify mode, llvm-rtdyld will test supplied expressions against the linked program images that it creates in memory. This scheme can be used to verify the correctness of the relocation logic applied by RuntimeDyld. The expressions to test will be read out of files passed via the -check option (there may be more than one of these). Expressions to check are extracted from lines of the form: # rtdyld-check: <expression> This system is designed to fit the llvm-lit regression test workflow. It is format and target agnostic, and supports verification of images linked for remote targets. The expression language is defined in llvm/include/llvm/RuntimeDyldChecker.h . Examples can be found in test/ExecutionEngine/RuntimeDyld. llvm-svn: 211956
* Silencing some -Wcast-qual warnings. No functional changes intended.Aaron Ballman2014-06-271-2/+2
| | | | llvm-svn: 211923
* [RuntimeDyld, PowerPC] Fix/improve handling of TOC relocationsUlrich Weigand2014-06-272-56/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [RuntimeDyld] Teach MachOObjectImage to deregister itself with the debugger uponLang Hames2014-06-261-1/+4
| | | | | | destruction the same way ELFObjectImage does. llvm-svn: 211815
* [RuntimeDyld] Adds the necessary hooks to MCJIT to be able to debug generatedLang Hames2014-06-252-9/+124
| | | | | | | | MachO files using the GDB JIT debugging interface. Patch by Keno Fischer. Thanks Keno! llvm-svn: 211652
* Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.Rafael Espindola2014-06-241-16/+20
| | | | | | | Once the objects are constructed, they own the buffer. Passing a unique_ptr makes that clear. llvm-svn: 211595
* Pass a std::unique_ptr& to the create??? methods is lib/Object.Rafael Espindola2014-06-231-1/+2
| | | | | | | | This makes the buffer ownership on error conditions very natural. The buffer is only moved out of the argument if an object is constructed that now owns the buffer. llvm-svn: 211546
* Revert "Replace Execution Engine's mutex with std::recursive_mutex."Zachary Turner2014-06-204-56/+57
| | | | | | | | | | This reverts commit 1f502bd9d7d2c1f98ad93a09ffe435e11a95aedd, due to GCC / MinGW's lack of support for C++11 threading. It's possible this will go back in after we come up with a reasonable solution. llvm-svn: 211401
* [RuntimeDyld] Fix ppc64 stub relocations on little-endianUlrich Weigand2014-06-201-5/+11
| | | | | | | | | | | | | | | When RuntimeDyldELF creates stub functions, it needs to install relocations that will resolve to the final address of the target routine. Since those are 16-bit relocs, they need to be applied to the least-significant halfword of the instruction. On big-endian ppc64, this means that addresses have to be adjusted by 2, which is what the code currently does. However, on a little-endian system, the address must *not* be adjusted; the least-significant halfword is the first one. This patch updates the RuntimeDyldELF code to take the target byte order into account. llvm-svn: 211384
* [RuntimeDyld] Support more PPC64 relocationsUlrich Weigand2014-06-201-4/+70
| | | | | | | | | | This adds support for several missing PPC64 relocations in the straight-forward manner to RuntimeDyldELF.cpp. Note that this actually fixes a failure of a large-model test case on PowerPC, allowing the XFAIL to be removed. llvm-svn: 211382
* Replace Execution Engine's mutex with std::recursive_mutex.Zachary Turner2014-06-184-57/+56
| | | | | | | | | | | | | This change has a bit of a trickle down effect due to the fact that there are a number of derived implementations of ExecutionEngine, and that the mutex is not tightly encapsulated so is used by other classes directly. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4196 llvm-svn: 211214
* Remove more occurrences of the unused-mutex-parameter pattern.Zachary Turner2014-06-171-16/+9
| | | | | | | | | | | | | | | | This pattern loses some of its usefulness when the mutex type is statically polymorphic as opposed to runtime polymorphic, as swapping out the mutex type requires changing a significant number of function parameters, and templatizing the function parameter requires the methods to be defined in the headers. Furthermore, if LLVM is compiled with threads disabled then there may even be no mutex to acquire anyway, so it should not be up to individual APIs to know whether or not acquiring a mutex is required to use those APIs to begin with. It should be up to the user of the API. llvm-svn: 211125
* Cleanup more unreferenced MutexGuard parameters on functions.Zachary Turner2014-06-163-29/+29
| | | | | | | | | | | These parameters are intended to serve as sort of a contract that you cannot access the functions outside of a mutex. However, the entire JIT class cannot be accessed outside of a mutex anyway, and all methods acquire a lock as soon as they are entered. Since the containing class already is not intended to be thread-safe, it only serves to add code clutter. llvm-svn: 211071
* Clean up some unnecessary mutex guards.Zachary Turner2014-06-161-25/+24
| | | | | | | | | | | | | | | These were being used as unreferenced parameters to enforce that the methods must not be called without holding a mutex, but all of the methods in question were internal, and the methods were only exposed through an interface whose entire purpose was to serialize access to these structures, so expecting the methods to be accessed under a mutex is reasonable enough. Reviewed by: blaikie Differential Revision: http://reviews.llvm.org/D4162 llvm-svn: 211054
* Convert the Archive API to use ErrorOr.Rafael Espindola2014-06-161-2/+6
| | | | | | | | | Now that we have c++11, even things like ErrorOr<std::unique_ptr<...>> are easy to use. No intended functionality change. llvm-svn: 211033
* Using llvm::sys::swapByteOrder() for the common case of byte-swapping a ↵Artyom Skrobov2014-06-141-3/+3
| | | | | | value in place llvm-svn: 210978
* Renaming SwapByteOrder() to getSwappedBytes()Artyom Skrobov2014-06-141-3/+3
| | | | | | The next commit will add swapByteOrder(), acting in-place llvm-svn: 210973
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-133-15/+12
| | | | llvm-svn: 210871
* Remove all uses of 'using std::error_code' from headers.Rafael Espindola2014-06-133-3/+3
| | | | llvm-svn: 210866
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-123-11/+14
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Remove system_error.h.Rafael Espindola2014-06-121-1/+1
| | | | | | | This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
* Add a Constant version of stripPointerCasts.Rafael Espindola2014-06-041-1/+1
| | | | | | Thanks to rnk for the suggestion. llvm-svn: 210205
* Allow alias to point to an arbitrary ConstantExpr.Rafael Espindola2014-06-031-2/+13
| | | | | | | | | | | | | | | | | | | | | This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is up to MC (or the system assembler) to decide if that expression is valid or not. This reduces our ability to diagnose invalid uses and how early we can spot them, but it also lets us do things like @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32), i32 ptrtoint (i32* @bar to i32)) to i32*) An important implication of this patch is that the notion of aliased global doesn't exist any more. The alias has to encode the information needed to access it in its metadata (linkage, visibility, type, etc). Another consequence to notice is that getSection has to return a "const char *". It could return a NullTerminatedStringRef if there was such a thing, but when that was proposed the decision was to just uses "const char*" for that. llvm-svn: 210062
* Updates in IntelJITEventListener.cpp - by Arch Robison.Elena Demikhovsky2014-06-011-2/+2
| | | | | | This patch updates IntelJITEventListener.cpp to account for revision 206654, which removed some methods from DILineInfo. llvm-svn: 209989
* ExecutionEngine: avoid NDEBUG in headersAlp Toker2014-05-311-0/+21
| | | | llvm-svn: 209981
* Use error_code() instead of error_code::succes()Rafael Espindola2014-05-311-1/+1
| | | | | | | There is no std::error_code::success, so this removes much of the noise in transitioning to std::error_code. llvm-svn: 209952
* AArch64/ARM64: move ARM64 into AArch64's placeTim Northover2014-05-242-4/+5
| | | | | | | | | | | | | | | This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency. "ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though. This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now. llvm-svn: 209577
* [RuntimeDyld] Remove relocation bounds check introduced in r208375 (MachO only).Lang Hames2014-05-231-4/+1
| | | | | | | | | | | | | | | | | | | We do all of our address arithmetic in 64-bit, and operations involving logically negative 32-bit offsets (actually represented as unsigned 64 bit ints) often overflow into higher bits. The overflow check could be preserved by casting to uint32 at the callsite for applyRelocationValue, but this would eliminate the value of the check. The right way to handle overflow in relocations is to make relocation processing target specific, and compute the values for RelocationEntry objects in the appropriate types (32-bit for 32-bit targets, 64-bit for 64-bit targets). This is coming as part of the cleanup I'm working on. This fixes another i386 regression test. <rdar://problem/16889891> llvm-svn: 209536
* [RuntimeDyld] Teach RuntimeDyldMachO how to handle scattered VANILLA relocs onLang Hames2014-05-222-9/+61
| | | | | | | | | | | | | | | | | | | | i386. This fixes two more MCJIT regression tests on i386: ExecutionEngine/MCJIT/2003-05-06-LivenessClobber.ll ExecutionEngine/MCJIT/2013-04-04-RelocAddend.ll The implementation of processScatteredVANILLA is tasteless (*ba-dum-ching*), but I'm working on a substantial tidy-up of RuntimeDyldMachO that should improve things. This patch also fixes a type-o in RuntimeDyldMachO::processSECTDIFFRelocation, and teaches that method to skip over the PAIR reloc following the SECTDIFF. <rdar://problem/16961886> llvm-svn: 209478
* [RuntimeDyld] Fix x86-64 MachO GOT relocation handling.Lang Hames2014-05-191-2/+7
| | | | | | | | | | | For GOT relocations the addend should modify the offset to the GOT entry, not the value of the entry itself. Teach RuntimeDyldMachO to do The Right Thing here. Fixes <rdar://problem/16961886>. llvm-svn: 209154
* Delete getAliasedGlobal.Rafael Espindola2014-05-161-1/+1
| | | | llvm-svn: 209040
* [RuntimeDyld] Fix handling of i386 PC-rel external relocations. This fixesLang Hames2014-05-131-0/+11
| | | | | | | | several more i386 MCJIT regression test failures. <rdar://problem/16889891> llvm-svn: 208735
* [un]wrap extracted from lib/Target/Target[MachineC].cpp, ↵Artyom Skrobov2014-05-131-8/+0
| | | | | | lib/ExecutionEngine/ExecutionEngineBindings.cpp into include/llvm/IR/DataLayout.h llvm-svn: 208680
* [RuntimeDyld] Add support for MachO __jump_table and __pointers sections, andLang Hames2014-05-126-16/+227
| | | | | | | | | | | 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
* [RuntimeDyld] Unify the RuntimeDyldMachO resolve.*Relocation method signaturesLang Hames2014-05-092-142/+121
| | | | | | | | | around RelocationEntries, rather than passing the same information via loose arguments. No functional change. llvm-svn: 208375
* Use range loop.Rafael Espindola2014-05-081-25/+21
| | | | llvm-svn: 208346
* Back out r208257 while I investigate tester failures.Lang Hames2014-05-071-14/+0
| | | | llvm-svn: 208267
* [RuntimeDyld] Make RuntimeDyldImpl::resolveExternalSymbols preserve theLang Hames2014-05-071-0/+14
| | | | | | | | | | | | | | | | | relocation entries it applies. Prior to this patch, RuntimeDyldImpl::resolveExternalSymbols discarded relocations for external symbols once they had been applied. This causes issues if the client calls MCJIT::finalizeLoadedModules more than once, and updates the location of any symbols in between (e.g. by calling MCJIT::mapSectionAddress). No test case yet: None of our in-tree memory managers support moving sections around. I'll have to hack up a dummy memory manager before I can write a unit test. Fixes <rdar://problem/16764378> llvm-svn: 208257
* [ARM64] Try and make the ELF MCJIT *slightly* less broken for ARM64.James Molloy2014-04-303-3/+11
| | | | | | | | | 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
* Fix the build with MSVC 2013 by explicitly requesting llvm::make_uniqueReid Kleckner2014-04-291-13/+17
| | | | | | | MSVC 2013 provides std::make_unique, which it finds with ADL when one of the parameters is std::unique_ptr, leading to an ambiguous overload. llvm-svn: 207597
* Fix MSVC build broken by r207580David Blaikie2014-04-291-0/+5
| | | | | | | | Seems MSVC wants to be able to codegen inline-definitions of virtual functions even in TUs that don't define the key function - and it's well within its rights to do so. llvm-svn: 207581
* PR19553: Memory leak in RuntimeDyldELF::createObjectImageFromFileDavid Blaikie2014-04-297-54/+75
| | | | | | | | | | | | | | | | 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
* [C++] Use 'nullptr'.Craig Topper2014-04-287-39/+40
| | | | llvm-svn: 207394
* [C++] Use 'nullptr'.Craig Topper2014-04-2412-72/+73
| | | | llvm-svn: 207083
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-2211-11/+22
| | | | | | | definition below all the header #include lines. This updates most of the miscellaneous other lib/... directories. A few left though. llvm-svn: 206845
* Revert "[rtdyld,c++11] Range'ify symbol table walking."Jim Grosbach2014-04-211-25/+33
| | | | | | | | | Tentative revert for http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/8305. This reverts commit c2a58efff07294fca724f89500538f2ddbcd12ff. llvm-svn: 206773
* [rtdyld,c++11] Range'ify symbol table walking.Jim Grosbach2014-04-211-33/+25
| | | | llvm-svn: 206769
* Convert getFileOffset to getOffset and move it to its only user.Rafael Espindola2014-04-211-9/+32
| | | | | | | | | | | | | We normally don't drop functions from the C API's, but in this case I think we can: * The old implementation of getFileOffset was fairly broken * The introduction of LLVMGetSymbolFileOffset was itself a C api breaking change as it removed LLVMGetSymbolOffset. * It is an incredibly specialized use case. The only reason MCJIT needs it is because of its odd position of being a dynamic linker of .o files. llvm-svn: 206750
* [ExecutionEngine] Allow JIT clients to enable/disable module verification.Lang Hames2014-04-183-14/+25
| | | | | | | | | | | | Previously module verification was always enabled, with no way to turn it off. As of this commit, module verification is on by default in Debug builds, and off by default in release builds. The default behaviour can be overridden by calling setVerifyModules(bool) on the JIT instance (this works for both the old JIT, and MCJIT). <rdar://problem/16150008> llvm-svn: 206561
* [Allocator] Finally, finish nuking the redundant code that led me hereChandler Carruth2014-04-151-7/+7
| | | | | | | | | | | | | | | | by removing the MallocSlabAllocator entirely and just using MallocAllocator directly. This makes all off these allocators expose and utilize the same core interface. The only ugly part of this is that it exposes the fact that the JIT allocator has no real handling of alignment, any more than the malloc allocator does. =/ It would be nice to fix both of these to support alignments, and then to leverage that in the BumpPtrAllocator to do less over allocation in order to manually align pointers. But, that's another patch for another day. This patch has no functional impact, it just removes the somewhat meaningless wrapper around MallocAllocator. llvm-svn: 206267
OpenPOWER on IntegriCloud