summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Reformat blank lines.NAKAMURA Takumi2016-07-041-2/+2
| | | | llvm-svn: 274481
* Reformat comment lines.NAKAMURA Takumi2016-07-041-1/+1
| | | | llvm-svn: 274480
* Untabify.NAKAMURA Takumi2016-07-041-4/+3
| | | | llvm-svn: 274479
* Reformat.NAKAMURA Takumi2016-07-041-4/+5
| | | | llvm-svn: 274478
* Fix lib/ExecutionEngine/IntelJITEvents/IntelJITEventListener.cpp for r273701Kevin Enderby2016-06-241-2/+5
| | | | | | and the change to libObject’s getSymbolAddress() to Expected<...> . llvm-svn: 273740
* Thread Expected<...> up from libObject’s getSymbolAddress() for symbols to ↵Kevin Enderby2016-06-241-4/+4
| | | | | | | | | | | | | | | | | | | | | allow a good error message to be produced. This is nearly the last libObject interface that used ErrorOr and the last one that appears in llvm/include/llvm/Object/MachO.h . For Mach-O objects this is just a clean up because it’s version of getSymbolAddress() can’t return an error. I will leave it to the experts on COFF and ELF to actually add meaning full error messages in their tests if they wish. And also leave it to these experts to change the last two ErrorOr interfaces in llvm/include/llvm/Object/ObjectFile.h for createCOFFObjectFile() and createELFObjectFile() if they wish. Since there are no test cases for COFF and ELF error cases with respect to getSymbolAddress() in the test suite this is no functional change (NFC). llvm-svn: 273701
* ExecutionEngine: silence unused value warningSaleem Abdulrasool2016-06-241-0/+3
| | | | | | | The Value is only used in debug or asserts builds. Just cast to void to silence an unused variable warning. llvm-svn: 273684
* ExecutionEngine: add preliminary support for COFF ARMSaleem Abdulrasool2016-06-242-5/+294
| | | | | | | | | This adds rudimentary support for COFF ARM to the dynamic loader for the exeuction engine. This can be used by lldb to JIT code into a COFF ARM environment. This lays the foundation for the loader, though a few of the relocation types are yet unhandled. llvm-svn: 273682
* IR: Introduce Module::global_objects().Peter Collingbourne2016-06-221-4/+2
| | | | | | | | | | | | This is a convenience iterator that allows clients to enumerate the GlobalObjects within a Module. Also start using it in a few places where it is obviously the right thing to use. Differential Revision: http://reviews.llvm.org/D21580 llvm-svn: 273470
* Apply another batch of fixes from clang-tidy's ↵Benjamin Kramer2016-06-171-2/+2
| | | | | | | | performance-unnecessary-value-param. Contains some manual fixes. No functionality change intended. llvm-svn: 273047
* [PATCH] Fix RuntimeDyldCOFFI386 to handle relocations with a non-zero addendReid Kleckner2016-06-161-3/+21
| | | | | | | | | This fixes IMAGE_REL_I386_DIR32, IMAGE_REL_I386_DIR32NB, IMAGE_REL_I386_SECREL, and IMAGE_REL_I386_REL32 relocations. Based on patch by Jon Turney <jon.turney@dronecode.org.uk> llvm-svn: 272911
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* [MCJIT] Update MCJIT and get the fibonacci example working again.Lang Hames2016-06-111-5/+9
| | | | | | | | | | MCJIT will now set the DataLayout on a module when it is added to the JIT, rather than waiting until it is codegen'd, and the runFunction method will finalize the module containing the function to be run before running it. The fibonacci example has been updated to include and link against MCJIT. llvm-svn: 272455
* Apply most suggestions of clang-tidy's performance-unnecessary-value-paramBenjamin Kramer2016-06-081-2/+3
| | | | | | | Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
* [Orc] Add conversion to/from RuntimeDyld::SymbolInfo for JITSymbol.Lang Hames2016-05-312-4/+4
| | | | | | | | | | This tidies up some code that was manually constructing RuntimeDyld::SymbolInfo instances from JITSymbols. It will save more mess in the future when JITSymbol::getAddress is extended to return an Expected<TargetAddress> rather than just a TargetAddress, since we'll be able to embed the error checking in the conversion. llvm-svn: 271350
* Apply clang-tidy's misc-move-constructor-init throughout LLVM.Benjamin Kramer2016-05-271-3/+5
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270997
* [Orc] Merge some common code for creating CompileCallbackManagers andLang Hames2016-05-265-73/+51
| | | | | | IndirectStubsManagers. llvm-svn: 270874
* [RuntimeDyld] Call the SymbolResolver::findSymbolInLogicalDylib method whenLang Hames2016-05-253-6/+8
| | | | | | | | | | | | | | | | | searching for external symbols, and fall back to the SymbolResolver::findSymbol method if the former returns null. This makes RuntimeDyld behave more like a static linker: Symbol definitions from within the current module's "logical dylib" will be preferred to external definitions. We can build on this behavior in the future to properly support weak symbol handling. Custom symbol resolvers that override the findSymbolInLogicalDylib method may notice changes due to this patch. Clients who have not overridden this method should generally be unaffected, however users of the OrcMCJITReplacement class may notice changes. llvm-svn: 270716
* Add FIXMEs to all derived classes of std::error_category.Peter Collingbourne2016-05-242-0/+6
| | | | | | | | This helps make clear that we're moving away from std::error_code. Differential Revision: http://reviews.llvm.org/D20592 llvm-svn: 270604
* [RuntimeDyld][MachO] Add support for SUBTRACTOR relocations between anonymousLang Hames2016-05-191-15/+52
| | | | | | symbols on x86-64. llvm-svn: 270157
* Delete Reloc::Default.Rafael Espindola2016-05-181-2/+1
| | | | | | | | | | | | Having an enum member named Default is quite confusing: Is it distinct from the others? This patch removes that member and instead uses Optional<Reloc> in places where we have a user input that still hasn't been maped to the default value, which is now clear has no be one of the remaining 3 options. llvm-svn: 269988
* [RuntimeDyld] Thread Error through some APIs, remove calls to ↵Lang Hames2016-05-184-58/+18
| | | | | | report_fatal_error. llvm-svn: 269881
* Change llvm-objdump, llvm-nm and llvm-size when reporting an object file errorKevin Enderby2016-05-172-4/+10
| | | | | | | | | | | | | | | | | | | | | when the object is in an archive to use something like libx.a(foo.o) as part of the error message. Also changed llvm-objdump and llvm-size to be like llvm-nm and ignore non-object files in archives and not produce any error message. To do this Archive::Child::getAsBinary() was changed from ErrorOr<...> to Expected<...> then that was threaded up to its users. Converting this interface to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now the use of errorToErrorCode() is still used in one place yet to be fully converted. Again 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 comments for those. llvm-svn: 269784
* [RuntimeDyld] Support R_390_PC64 relocation typeBryan Chan2016-05-131-0/+5
| | | | | | | | | | | | Summary: When the MCJIT generates ELF code, some DWARF data requires 64-bit PC-relative relocation (R_390_PC64). This patch adds support for R_390_PC64 relocation to RuntimeDyld::resolveSystemZRelocation, to avoid an assertion failure. Reviewers: uweigand Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D20033 llvm-svn: 269436
* [Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support.Lang Hames2016-05-073-81/+171
| | | | | | | | This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
* Thread Expected<...> up from libObject’s getType() for symbols to allow ↵Kevin Enderby2016-05-025-11/+43
| | | | | | | | | | | | | | | | | | | | | | llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s section index is more than the number of sections. The existing test case in test/Object/macho-invalid.test for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating that a symbol at a specific index has a bad section index and that bad section index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. 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(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. llvm-svn: 268298
* [ORC] Save AArch64 NEON state in the JIT reentry block.Lang Hames2016-05-011-42/+74
| | | | | | | The earlier version of the resolver code did not save NEON state, so it would have broken any callees that used floating point. llvm-svn: 268173
* [Orc] Add ORC lazy-compilation support for AArch64.Lang Hames2016-04-291-0/+144
| | | | | | | The ORC compile callbacks and indirect stubs APIs will now work for AArc64, allowing functions to be lazily compiled and/or updated. llvm-svn: 268112
* Use llvm:Twine instead of std::to_string.Chaoren Lin2016-04-283-11/+11
| | | | | | | | | | | | std::to_string is not available from the Android NDK. Reviewers: lhames, ovyalov, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19638 llvm-svn: 267829
* [RuntimeDyld] Propagate another dropped error in RuntimeDyldELF.Lang Hames2016-04-271-1/+2
| | | | | | This should fix the PPC64 bots. llvm-svn: 267810
* [RuntimeDyld] Add missing include - <string> is requried for std::to_string.Lang Hames2016-04-273-0/+3
| | | | | | | This should fix the compile error that showed up in build: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/6754/ llvm-svn: 267790
* [RuntimeDyld] Propagate Errors from findPPC64TOCSection.Lang Hames2016-04-271-3/+6
| | | | llvm-svn: 267789
* [RuntimeDyld] Plumb Error/Expected through the internals of RuntimeDyld.Lang Hames2016-04-2713-288/+471
| | | | | | | | | | | | | 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
* [ORC] clang-format code that was touched in r267457. NFC.Lang Hames2016-04-255-213/+189
| | | | | | | Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
* [ORC] Thread Error/Expected through the RPC library.Lang Hames2016-04-254-26/+55
| | | | | | | | | | This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
* [RuntimeDyldELF] Handle GOTPCRELX/REX_GOTPCRELX.Davide Italiano2016-04-241-1/+5
| | | | llvm-svn: 267309
* [RuntimeDyld] Fix conservative over-allocation of memory for common symbols.Lang Hames2016-04-211-4/+14
| | | | | | | | | The previous allocation code was over-estimating the amount of memory required. No test case: we don't currently have a good way to detect conervative over-allocation. llvm-svn: 267041
* Fix another compilation error from r266919 for clang-atom-d525-fedora-rel whichKevin Enderby2016-04-201-2/+5
| | | | | | | is another place that libObject’s getName() for symbols returns Expected<...> that needed to be updated. llvm-svn: 266933
* Thread Expected<...> up from libObject’s getName() for symbols to allow ↵Kevin Enderby2016-04-209-36/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test for macho-invalid-symbol-name-past-eof now reports the error with the message indicating that a symbol at a specific index has a bad sting index and that bad string index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. There is some code for this that could be factored into a routine but I would like to leave that for the code owners post-commit to do as they want for handling an llvm::Error. An example of how this could be done is shown in the diff in lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine already for std::error_code so I added one like it for llvm::Error . 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(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there fixes needed to lld 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: 266919
* [Orc] Re-commit r266581 with fixes for MSVC, and format cleanups.Lang Hames2016-04-182-35/+27
| | | | | | | | | | Fixes: (1) Removes constexpr (unsupported in MSVC) (2) Move constructors (remove explicitly defaulted ones) (3) <future> - Add warning suppression for MSVC. llvm-svn: 266663
* Revert 266581 (and follow-up 266588), it doesn't build on Windows.Nico Weber2016-04-182-27/+35
| | | | | | | | | | Three problems: 1. <future> can't be easily used. If you must use it, see include/Support/ThreadPool.h for how. 2. constexpr problems, even after 266588. 3. Move assignment operators can't be defaulted in MSVC2013. llvm-svn: 266615
* [NFC] Header cleanupMehdi Amini2016-04-188-10/+1
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* [ORC] Generalize the ORC RPC utils to support RPC function return values andLang Hames2016-04-182-35/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | asynchronous call/handle. Also updates the ORC remote JIT API to use the new scheme. The previous version of the RPC tools only supported void functions, and required the user to manually call a paired function to return results. This patch replaces the Procedure typedef (which only supported void functions) with the Function typedef which supports return values, e.g.: Function<FooId, int32_t(std::string)> Foo; The RPC primitives and channel operations are also expanded. RPC channels must support four new operations: startSendMessage, endSendMessage, startRecieveMessage and endRecieveMessage, to handle channel locking. In addition, serialization support for tuples to RPCChannels is added to enable multiple return values. The RPC primitives are expanded from callAppend, call, expect and handle, to: appendCallAsync - Make an asynchronous call to the given function. callAsync - The same as appendCallAsync, but calls send on the channel when done. callSTHandling - Blocking call for single-threaded code. Wraps a call to callAsync then waits on the result, using a user-supplied handler to handle any callbacks from the remote. callST - The same as callSTHandling, except that it doesn't handle callbacks - it expects the result to be the first return. expect and handle - as before. handleResponse - Handle a response from the remote. waitForResult - Wait for the response with the given sequence number to arrive. llvm-svn: 266581
* 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
* More more change need as part of r264187 where ErrorOr<> was addedKevin Enderby2016-03-231-1/+5
| | | | | | to getSymbolType(). llvm-svn: 264194
* Fix a crash in running llvm-objdump -t with an invalid Mach-O file alreadyKevin Enderby2016-03-232-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the test suite. While this is not really an interesting tool and option to run on a Mach-O file to show the symbol table in a generic libObject format it shouldn’t crash. The reason for the crash was in MachOObjectFile::getSymbolType() when it was calling MachOObjectFile::getSymbolSection() without checking its return value for the error case. What makes this fix require a fair bit of diffs is that the method getSymbolType() is in the class ObjectFile defined without an ErrorOr<> so I needed to add that all the sub classes.  And all of the uses needed to be updated and the return value needed to be checked for the error case. The MachOObjectFile version of getSymbolType() “can” get an error in trying to come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol symbol type is an N_SECT type because the code is trying to select from the SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type. And it needs the Mach-O section to use isData() and isBSS to determine if it will return SymbolRef::ST_Data. One other possible fix I considered is to simply return SymbolRef::ST_Other when MachOObjectFile::getSymbolSection() returned an error. But since in the past when I did such changes that “ate an error in the libObject code” I was asked instead to push the error out of the libObject code I chose not to implement the fix this way. As currently written both the COFF and ELF versions of getSymbolType() can’t get an error. But if isReservedSectionNumber() wanted to check for the two known negative values rather than allowing all negative values or the code wanted to add the same check as in getSymbolAddress() to use getSection() and check for the error then these versions of getSymbolType() could return errors. At the end of the day the error printed now is the generic “Invalid data was encountered while parsing the file” for object_error::parse_failed. In the future when we thread Lang’s new TypedError for recoverable error handling though libObject this will improve. And where the added // Diagnostic(… comment is, it would be changed to produce and error message like “bad section index (42) for symbol at index 8” for this case. llvm-svn: 264187
* ExecutionEngine: tweak debug logSaleem Abdulrasool2016-03-051-1/+1
| | | | | | Add a newline to separate the log message. NFC. llvm-svn: 262777
* [RuntimeDyld] Fix '_' stripping in ↵Lang Hames2016-03-031-8/+6
| | | | | | | | | | | | | | | | | | | | | | | RTDyldMemoryManager::getSymbolAddressInProcess. The RTDyldMemoryManager::getSymbolAddressInProcess method accepts a linker-mangled symbol name, but it calls through to dlsym to do the lookup (via DynamicLibrary::SearchForAddressOfSymbol), and dlsym expects an unmangled symbol name. Historically we've attempted to "demangle" by removing leading '_'s on all platforms, and fallen back to an extra search if that failed. That's broken, as it can cause symbols to resolve incorrectly on platforms that don't do mangling if you query '_foo' and the process also happens to contain a 'foo'. Fix this by demangling conditionally based on the host platform. That's safe here because this function is specifically for symbols in the host process, so the usual cross-process JIT looking concerns don't apply. M unittests/ExecutionEngine/ExecutionEngineTest.cpp M lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp llvm-svn: 262657
* Refactor duplicated code for linking with pthread.Rafael Espindola2016-03-011-3/+3
| | | | llvm-svn: 262344
OpenPOWER on IntegriCloud