summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby2016-04-061-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
* Reapply r250906 with many suggested updates from Rafael Espindola.Kevin Enderby2015-11-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The needed lld matching changes to be submitted immediately next, but this revision will cause lld failures with this alone which is expected. This removes the eating of the error in Archive::Child::getSize() when the characters in the size field in the archive header for the member is not a number. To do this we have all of the needed methods return ErrorOr to push them up until we get out of lib. Then the tools and can handle the error in whatever way is appropriate for that tool. So the solution is to plumb all the ErrorOr stuff through everything that touches archives. This include its iterators as one can create an Archive object but the first or any other Child object may fail to be created due to a bad size field in its header. Thanks to Lang Hames on the changes making child_iterator contain an ErrorOr<Child> instead of a Child and the needed changes to ErrorOr.h to add operator overloading for * and -> . We don’t want to use llvm_unreachable() as it calls abort() and is produces a “crash” and using report_fatal_error() to move the error checking will cause the program to stop, neither of which are really correct in library code. There are still some uses of these that should be cleaned up in this library code for other than the size field. The test cases use archives with text files so one can see the non-digit character, in this case a ‘%’, in the size field. These changes will require corresponding changes to the lld project. That will be committed immediately after this change. But this revision will cause lld failures with this alone which is expected. llvm-svn: 252192
* Backing out commit r250906 as it broke lld.Kevin Enderby2015-10-211-2/+2
| | | | llvm-svn: 250908
* This removes the eating of the error in Archive::Child::getSize() when the ↵Kevin Enderby2015-10-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | characters in the size field in the archive header for the member is not a number. To do this we have all of the needed methods return ErrorOr to push them up until we get out of lib. Then the tools and can handle the error in whatever way is appropriate for that tool. So the solution is to plumb all the ErrorOr stuff through everything that touches archives. This include its iterators as one can create an Archive object but the first or any other Child object may fail to be created due to a bad size field in its header. Thanks to Lang Hames on the changes making child_iterator contain an ErrorOr<Child> instead of a Child and the needed changes to ErrorOr.h to add operator overloading for * and -> . We don’t want to use llvm_unreachable() as it calls abort() and is produces a “crash” and using report_fatal_error() to move the error checking will cause the program to stop, neither of which are really correct in library code. There are still some uses of these that should be cleaned up in this library code for other than the size field. Also corrected the code where the size gets us to the “at the end of the archive” which is OK but past the end of the archive will return object_error::parse_failed now. The test cases use archives with text files so one can see the non-digit character, in this case a ‘%’, in the size field. llvm-svn: 250906
* Remove and forbid raw_svector_ostream::flush() calls.Yaron Keren2015-08-131-1/+0
| | | | | | | | | | After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as the stream and its SmallString are always in sync. Thanks to David Blaikie for reviewing. llvm-svn: 244928
* [MCJIT] Fix PR20656 by teaching MCJIT to honor ExecutionEngine's global mapping.Lang Hames2015-07-291-0/+6
| | | | | | | This is important for users of the C API who can't supply custom symbol resolvers yet. llvm-svn: 243589
* Remove access to the DataLayout in the TargetMachineMehdi Amini2015-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243114
* Revert "Remove access to the DataLayout in the TargetMachine"Mehdi Amini2015-07-241-1/+1
| | | | | | | | | | This reverts commit 0f720d984f419c747709462f7476dff962c0bc41. It breaks clang too badly, I need to prepare a proper patch for clang first. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243089
* Remove access to the DataLayout in the TargetMachineMehdi Amini2015-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243083
* Make ExecutionEngine owning a DataLayoutMehdi Amini2015-07-161-7/+11
| | | | | | | | | | | | | | | | | | | | Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. The ExecutionEngine will act as an exception and will be unsafe to be reused across context. We don't enforce this rule but undefined behavior can occurs if the user tries to do it. Reviewers: lhames Subscribers: echristo, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11110 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 242414
* Revert "Make ExecutionEngine owning a DataLayout"Michael Kuperstein2015-07-161-11/+7
| | | | | | | | Reverting to fix buildbot breakage. This reverts commit r242387. llvm-svn: 242394
* Make ExecutionEngine owning a DataLayoutMehdi Amini2015-07-161-7/+11
| | | | | | | | | | | | | | | | | | | | Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. The ExecutionEngine will act as an exception and will be unsafe to be reused across context. We don't enforce this rule but undefined behavior can occurs if the user tries to do it. Reviewers: lhames Subscribers: echristo, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11110 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 242387
* Be sure to set the DataLayout before checking the cache.Rafael Espindola2015-06-231-2/+2
| | | | | | | | This makes sure the same mangling is used. Should fix the OS X bots. llvm-svn: 240411
* Simplify the Mangler interface now that DataLayout is mandatory.Rafael Espindola2015-06-231-3/+2
| | | | | | | We only need to pass in a DataLayout when mangling a raw string, not when constructing the mangler. llvm-svn: 240405
* [MCJIT] Add a FindGlobalVariableNamed utilityKeno Fischer2015-06-201-0/+25
| | | | | | | | | | | | | | | | Summary: This adds FindGlobalVariableNamed to ExecutionEngine (plus implementation in MCJIT), which is an analog of FindFunctionNamed for GlobalVariables. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10421 llvm-svn: 240202
* [ExecutionEngine] ArrayRefize argument passing.Benjamin Kramer2015-06-131-2/+1
| | | | | | No functionality change intended. llvm-svn: 239687
* [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames2015-03-301-33/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Orc][MCJIT][RuntimeDyld] Re-apply r231726 and r231724 with fix suggested byLang Hames2015-03-111-2/+2
| | | | | | Dave Blaikie. Thanks Dave! llvm-svn: 231896
* Temporarily revert r231726 and r231724 as they're breaking the build.:Eric Christopher2015-03-101-2/+2
| | | | | | | | | | | | | | | | | | | Author: Lang Hames <lhames@gmail.com> Date: Mon Mar 9 23:51:09 2015 +0000 [Orc][MCJIT][RuntimeDyld] Add header that was accidentally left out of r231724. Author: Lang Hames <lhames@gmail.com> Date: Mon Mar 9 23:44:13 2015 +0000 [Orc][MCJIT][RuntimeDyld] Add symbol flags to symbols in RuntimeDyld. Thread the new types through MCJIT and Orc. In particular, add a 'weak' flag. When plumbed through RTDyldMemoryManager, this will allow us to distinguish between weak and strong definitions and find the right ones during symbol resolution. llvm-svn: 231731
* [Orc][MCJIT][RuntimeDyld] Add symbol flags to symbols in RuntimeDyld. Thread theLang Hames2015-03-091-2/+2
| | | | | | | | | | new types through MCJIT and Orc. In particular, add a 'weak' flag. When plumbed through RTDyldMemoryManager, this will allow us to distinguish between weak and strong definitions and find the right ones during symbol resolution. llvm-svn: 231724
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* [PM] Remove the old 'PassManager.h' header file at the top level ofChandler Carruth2015-02-131-2/+2
| | | | | | | | | | | | | | | | | | | | LLVM's include tree and the use of using declarations to hide the 'legacy' namespace for the old pass manager. This undoes the primary modules-hostile change I made to keep out-of-tree targets building. I sent an email inquiring about whether this would be reasonable to do at this phase and people seemed fine with it, so making it a reality. This should allow us to start bootstrapping with modules to a certain extent along with making it easier to mix and match headers in general. The updates to any code for users of LLVM are very mechanical. Switch from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h". Qualify the types which now produce compile errors with "legacy::". The most common ones are "PassManager", "PassManagerBase", and "FunctionPassManager". llvm-svn: 229094
* [ExecutionEngine] FindFunctionNamed: Skip declarationsKeno Fischer2015-01-271-1/+2
| | | | | | | | | | | | | | | | Summary: Basically all other methods that look up functions by name skip them if they are mere declarations. Do the same in FindFunctionNamed. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7068 llvm-svn: 227227
* Remove some extraneous includes.Eric Christopher2015-01-271-2/+0
| | | | llvm-svn: 227180
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-261-4/+4
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
* [MCJIT] Unique-ptrify the RTDyldMemoryManager member of MCJIT. NFC.Lang Hames2014-12-031-5/+8
| | | | llvm-svn: 223183
* [MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.Lang Hames2014-11-261-33/+38
| | | | llvm-svn: 222840
* Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman2014-11-261-38/+33
| | | | | | 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-261-33/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] 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-151-2/+1
| | | | | | | | | 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-051-5/+7
| | | | | | | | | | | 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-031-4/+4
| | | | llvm-svn: 217067
* unique_ptrify a bunch of stuff through RuntimeDyld::loadObjectDavid Blaikie2014-09-031-18/+13
| | | | llvm-svn: 217065
* unique_ptrify passing the TargetMachine to ExecutionEngine::MCJITCtorDavid Blaikie2014-09-021-7/+5
| | | | llvm-svn: 216988
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-021-15/+3
| | | | | | | | 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-261-3/+5
| | | | | | | 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-191-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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-191-15/+19
| | | | 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
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-071-3/+15
| | | | | | | | | | | 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-071-15/+3
| | | | | | | | | 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
OpenPOWER on IntegriCloud