summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/MCJIT
Commit message (Collapse)AuthorAgeFilesLines
...
* [MCJIT] Unique-ptrify the RTDyldMemoryManager member of MCJIT. NFC.Lang Hames2014-12-032-9/+13
| | | | llvm-svn: 223183
* [MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.Lang Hames2014-11-263-39/+93
| | | | llvm-svn: 222840
* Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman2014-11-263-93/+39
| | | | | | http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/11753 llvm-svn: 222833
* [MCJIT] Re-enable GDB registration (temporarily disabled in r222811), but checkLang Hames2014-11-261-0/+1
| | | | | | | | | | that we actually have an object to register first. For MachO objects, RuntimeDyld::LoadedObjectInfo::getObjectForDebug returns an empty OwningBinary<ObjectFile> which was causing crashes in the GDB registration code. llvm-svn: 222812
* [MCJIT] Temporarily disable automatic JIT debugger registration.Lang Hames2014-11-261-1/+0
| | | | | | | | | The RuntimeDyld cleanup patch r222810 turned on GDB registration for MachO objects. I expected this to be harmless, but it seems to have broken on MacsOS. Temporarily disabling debugger registration while I dig in to what's gone wrong. llvm-svn: 222811
* [MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.Lang Hames2014-11-263-39/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Object] Modify OwningBinary's interface to separate inspection from ownership.Lang Hames2014-10-311-3/+6
| | | | | | | | The getBinary and getBuffer method now return ordinary pointers of appropriate const-ness. Ownership is transferred by calling takeBinary(), which returns a pair of the Binary and a MemoryBuffer. llvm-svn: 221003
* [MCJIT] Make repeat calls to MCJIT::getPointerToFunction for declarations safe.Lang Hames2014-10-221-1/+1
| | | | | | | | | | | | | | MCJIT::getPointerForFunction adds the resulting address to the global mapping. This should be done via updateGlobalMapping rather than addGlobalMapping, since the latter asserts if a mapping already exists. MCJIT::getPointerToFunction is actually deprecated - hopefully we can remove it (or more likely re-task it) entirely soon. In the mean time it should at least work as advertised. <rdar://problem/18727946> llvm-svn: 220444
* [MCJIT] Remove #include of JITMemoryManager that accidentally survived r218316.Lang Hames2014-09-231-1/+0
| | | | llvm-svn: 218317
* [MCJIT] Delete the JTIMemoryManager and associated APIs.Lang Hames2014-09-232-901/+0
| | | | | | | | | | This patch removes the old JIT memory manager (which does not provide any useful functionality now that the old JIT is gone), and migrates the few remaining clients over to SectionMemoryManager. http://llvm.org/PR20848 llvm-svn: 218316
* [MCJIT] Make RTDyldMemoryManager::getSymbolAddress's behaviour more consistent.Lang Hames2014-09-201-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch modifies RTDyldMemoryManager::getSymbolAddress(Name)'s behavior to make it consistent with how clients are using it: Name should be mangled, and getSymbolAddress should demangle it on the caller's behalf before looking the name up in the process. This patch also fixes the one client (MCJIT::getPointerToFunction) that had been passing unmangled names (by having it pass mangled names instead). Background: RTDyldMemoryManager::getSymbolAddress(Name) has always used a re-try mechanism when looking up symbol names in the current process. Prior to this patch getSymbolAddress first tried to look up 'Name' exactly as the user passed it in and then, if that failed, tried to demangle 'Name' and re-try the look up. The implication of this behavior is that getSymbolAddress expected to be called with unmangled names, and that handling mangled names was a fallback for convenience. This is inconsistent with how clients (particularly the RuntimeDyldImpl subclasses, but also MCJIT) usually use this API. Most clients pass in mangled names, and succeed only because of the fallback case. For clients passing in mangled names, getSymbolAddress's old behavior was actually dangerous, as it could cause unmangled names in the process to shadow mangled names being looked up. For example, consider: foo.c: int _x = 7; int x() { return _x; } foo.o: 000000000000000c D __x 0000000000000000 T _x If foo.c becomes part of the process (E.g. via dlopen("libfoo.dylib")) it will add symbols 'x' (the function) and '_x' (the variable) to the process. However jit clients looking for the function 'x' will be using the mangled function name '_x' (note how function 'x' appears in foo.o). When getSymbolAddress goes looking for '_x' it will find the variable instead, and return its address and in place of the function, leading to JIT'd code calling the variable and crashing (if we're lucky). By requiring that getSymbolAddress be called with mangled names, and demangling only when we're about to do a lookup in the process, the new behavior implemented in this patch should eliminate any chance of names being shadowed during lookup. There's no good way to test this at the moment: This issue only arrises when looking up process symbols (not JIT'd symbols). Any test case would have to generate a platform-appropriate dylib to pass to llvm-rtdyld, and I'm not aware of any in-tree tool for doing this in a portable way. llvm-svn: 218187
* [MCJIT] Start Stringref-izing the ExecutionEngine interface.Lang Hames2014-09-152-3/+2
| | | | | | | | | More methods to follow. Using StringRef allows us the EE interface to work with more string types without forcing construction of std::strings. llvm-svn: 217794
* Add doInitialization/doFinalization to DataLayoutPass.Rafael Espindola2014-09-101-1/+1
| | | | | | | | | | | | | With this a DataLayoutPass can be reused for multiple modules. Once we have doInitialization/doFinalization, it doesn't seem necessary to pass a Module to the constructor. Overall this change seems in line with the idea of making DataLayout a required part of Module. With it the only way of having a DataLayout used is to add it to the Module. llvm-svn: 217548
* [MCJIT] Fix an iterator invalidation bug in MCJIT::finalizeObject.Lang Hames2014-09-052-5/+10
| | | | | | | | | | | The finalizeObject method calls generateCodeForModule on each of the currently 'added' objects, but generateCodeForModule moves objects out of the 'added' set as it's called. To avoid iterator invalidation issues, the added set is copied out before any calls to generateCodeForModule. This should fix http://llvm.org/PR20851 . llvm-svn: 217291
* Fix use-after-move introduced in r217065 and caught in post-commit review by ↵David Blaikie2014-09-041-2/+2
| | | | | | Alexey. llvm-svn: 217181
* unique_ptrify MCJIT::emitObjectDavid Blaikie2014-09-032-5/+5
| | | | llvm-svn: 217067
* unique_ptrify a bunch of stuff through RuntimeDyld::loadObjectDavid Blaikie2014-09-032-20/+14
| | | | llvm-svn: 217065
* unique_ptrify passing the TargetMachine to ExecutionEngine::MCJITCtorDavid Blaikie2014-09-022-11/+9
| | | | llvm-svn: 216988
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-024-22/+905
| | | | | | | | Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
* Give ExecutionEngine of top level buffers.Rafael Espindola2014-08-262-3/+7
| | | | | | | Long term the idea if for the engine to not own the buffers, but for now this is consistent with the rest of the API. llvm-svn: 216484
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-192-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make it explicit that ExecutionEngine takes ownership of the modules.Rafael Espindola2014-08-192-20/+25
| | | | llvm-svn: 215967
* Use copy initialization to initialize std::unique_ptr.Rafael Espindola2014-08-171-1/+1
| | | | | | Thanks to David Blaikie for the suggestion. llvm-svn: 215867
* [MCJIT] Support DisableSymbolSearching and InstallLazyFunctionCreator in MCJIT.Lang Hames2014-08-141-5/+13
| | | | | | Patch by Anthony Pesch. Thanks Anthony! llvm-svn: 215613
* 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
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-074-909/+22
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* Nuke the old JIT.Rafael Espindola2014-08-074-22/+909
| | | | | | | | | I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-4/+5
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Replace comment about ownership with std::unique_ptr.Rafael Espindola2014-08-012-9/+5
| | | | llvm-svn: 214533
* Use range loop.Rafael Espindola2014-08-011-7/+3
| | | | llvm-svn: 214530
* Remove some calls to std::move.Rafael Espindola2014-08-011-1/+1
| | | | | | | | | Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get a reference to it. Thanks to David Blaikie for the suggestion. llvm-svn: 214516
* Delete dead code.Rafael Espindola2014-07-312-8/+3
| | | | llvm-svn: 214370
* Revert "Replace Execution Engine's mutex with std::recursive_mutex."Zachary Turner2014-06-201-18/+19
| | | | | | | | | | 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
* Replace Execution Engine's mutex with std::recursive_mutex.Zachary Turner2014-06-181-19/+18
| | | | | | | | | | | | | 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
* 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
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-121-11/+12
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* 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
* PR19553: Memory leak in RuntimeDyldELF::createObjectImageFromFileDavid Blaikie2014-04-292-6/+6
| | | | | | | | | | | | | | | | 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-281-1/+1
| | | | llvm-svn: 207394
* [C++] Use 'nullptr'.Craig Topper2014-04-242-12/+12
| | | | llvm-svn: 207083
* [ExecutionEngine] Allow JIT clients to enable/disable module verification.Lang Hames2014-04-181-1/+2
| | | | | | | | | | | | 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
* LLVMBuild.txt: Add missing dependencies.NAKAMURA Takumi2014-04-101-1/+1
| | | | llvm-svn: 205962
* [MCJIT] Check if there have been errors during RuntimeDyld execution.Juergen Ributzka2014-03-261-1/+1
| | | | llvm-svn: 204837
* Add an option to MCJIT to have it forward all sections to theLang Hames2014-03-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | RTDyldMemoryManager, regardless of whether it thinks they're "required for execution". Currently, RuntimeDyld only passes sections that are "required for execution" to the RTDyldMemoryManager, and takes "required for execution" to mean exactly "contains symbols or relocations". There are two problems with this: (1) It can drop sections with anonymous data that is referenced by code. (2) It leaves the JIT client no way to inspect interesting sections that aren't actually required to run the program (e.g dwarf sections). A test case is still in the works. Future work: We may want to replace this with a generic section filtering mechanism, but that will require more consideration. For now, this flag at least allows clients to volunteer to do the filtering themselves. Fixes <rdar://problem/15177691>. llvm-svn: 204398
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-081-42/+43
| | | | | | class. llvm-svn: 203344
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-062-6/+6
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles2014-03-051-4/+4
| | | | llvm-svn: 202957
* Use DataLayout from the module when easily available.Rafael Espindola2014-02-251-1/+2
| | | | | | | | | | | | | | | | | Eventually DataLayoutPass should go away, but for now that is the only easy way to get a DataLayout in some APIs. This patch only changes the ones that have easy access to a Module. One interesting issue with sometimes using DataLayoutPass and sometimes fetching it from the Module is that we have to make sure they are equivalent. We can get most of the way there by always constructing the pass with a Module. In fact, the pass could be changed to point to an external DataLayout instead of owning one to make this stricter. Unfortunately, the C api passes a DataLayout, so it has to be up to the caller to make sure the pass and the module are in sync. llvm-svn: 202204
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-251-1/+1
| | | | | | | Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
* move getNameWithPrefix and getSymbol to TargetMachine.Rafael Espindola2014-02-191-1/+1
| | | | | | | | | | TargetLoweringBase is implemented in CodeGen, so before this patch we had a dependency fom Target to CodeGen. This would show up as a link failure of llvm-stress when building with -DBUILD_SHARED_LIBS=ON. This fixes pr18900. llvm-svn: 201711
OpenPOWER on IntegriCloud