summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
...
* Initial implementation of JITLink - A replacement for RuntimeDyld.Lang Hames2019-04-2018-65/+3140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: JITLink is a jit-linker that performs the same high-level task as RuntimeDyld: it parses relocatable object files and makes their contents runnable in a target process. JITLink aims to improve on RuntimeDyld in several ways: (1) A clear design intended to maximize code-sharing while minimizing coupling. RuntimeDyld has been developed in an ad-hoc fashion for a number of years and this had led to intermingling of code for multiple architectures (e.g. in RuntimeDyldELF::processRelocationRef) in a way that makes the code more difficult to read, reason about, extend. JITLink is designed to isolate format and architecture specific code, while still sharing generic code. (2) Support for native code models. RuntimeDyld required the use of large code models (where calls to external functions are made indirectly via registers) for many of platforms due to its restrictive model for stub generation (one "stub" per symbol). JITLink allows arbitrary mutation of the atom graph, allowing both GOT and PLT atoms to be added naturally. (3) Native support for asynchronous linking. JITLink uses asynchronous calls for symbol resolution and finalization: these callbacks are passed a continuation function that they must call to complete the linker's work. This allows for cleaner interoperation with the new concurrent ORC JIT APIs, while still being easily implementable in synchronous style if asynchrony is not needed. To maximise sharing, the design has a hierarchy of common code: (1) Generic atom-graph data structure and algorithms (e.g. dead stripping and | memory allocation) that are intended to be shared by all architectures. | + -- (2) Shared per-format code that utilizes (1), e.g. Generic MachO to | atom-graph parsing. | + -- (3) Architecture specific code that uses (1) and (2). E.g. JITLinkerMachO_x86_64, which adds x86-64 specific relocation support to (2) to build and patch up the atom graph. To support asynchronous symbol resolution and finalization, the callbacks for these operations take continuations as arguments: using JITLinkAsyncLookupContinuation = std::function<void(Expected<AsyncLookupResult> LR)>; using JITLinkAsyncLookupFunction = std::function<void(const DenseSet<StringRef> &Symbols, JITLinkAsyncLookupContinuation LookupContinuation)>; using FinalizeContinuation = std::function<void(Error)>; virtual void finalizeAsync(FinalizeContinuation OnFinalize); In addition to its headline features, JITLink also makes other improvements: - Dead stripping support: symbols that are not used (e.g. redundant ODR definitions) are discarded, and take up no memory in the target process (In contrast, RuntimeDyld supported pointer equality for weak definitions, but the redundant definitions stayed resident in memory). - Improved exception handling support. JITLink provides a much more extensive eh-frame parser than RuntimeDyld, and is able to correctly fix up many eh-frame sections that RuntimeDyld currently (silently) fails on. - More extensive validation and error handling throughout. This initial patch supports linking MachO/x86-64 only. Work on support for other architectures and formats will happen in-tree. Differential Revision: https://reviews.llvm.org/D58704 llvm-svn: 358818
* Simplify decoupling between RuntimeDyld/RuntimeDyldChecker, add 'got_addr' util.Lang Hames2019-04-1212-134/+101
| | | | | | | | | | | | | | | | | | | | | | | | | This patch reduces the number of functions in the interface between RuntimeDyld and RuntimeDyldChecker by combining "GetXAddress" and "GetXContent" functions into "GetXInfo" functions that return a struct describing both the address and content. The GetStubOffset function is also replaced with a pair of utilities, GetStubInfo and GetGOTInfo, that fit the new scheme. For RuntimeDyld both of these functions will return the same result, but for the new JITLink linker (https://reviews.llvm.org/D58704) these will provide the addresses of PLT stubs and GOT entries respectively. For JITLink's use, a 'got_addr' utility has been added to the rtdyld-check language, and the syntax of 'got_addr' and 'stub_addr' has been changed: both functions now take two arguments, a 'stub container name' and a target symbol name. For llvm-rtdyld/RuntimeDyld the stub container name is the object file name and section name, separated by a slash. E.g.: rtdyld-check: *{8}(stub_addr(foo.o/__text, y)) = y For the upcoming llvm-jitlink utility, which creates stubs on a per-file basis rather than a per-section basis, the container name is just the file name. E.g.: jitlink-check: *{8}(got_addr(foo.o, y)) = y llvm-svn: 358295
* gn build: Fix Windows builds after r357797Nico Weber2019-04-091-1/+1
| | | | llvm-svn: 358004
* [RuntimeDyld] Fix an ambiguous make_unique call.Lang Hames2019-04-081-1/+1
| | | | llvm-svn: 357950
* [RuntimeDyld] Decouple RuntimeDyldChecker from RuntimeDyld.Lang Hames2019-04-085-283/+230
| | | | | | | This will allow RuntimeDyldChecker (and rtdyld-check tests) to test a new JIT linker: JITLink (https://reviews.llvm.org/D58704). llvm-svn: 357947
* Change some StringRef::data() reinterpret_cast to bytes_begin() or ↵Fangrui Song2019-04-071-3/+1
| | | | | | arrayRefFromStringRef() llvm-svn: 357852
* [DebugInfo] IntelJitEventListener follow up for "add SectionedAddress ..."Brock Wyma2019-03-251-3/+13
| | | | | | | | | | | | Following r354972 the Intel JIT Listener would not report line table information because the section indices did not match. There was a similar issue with the PerfJitEventListener. This change performs the section index lookup when building the object address used to query the line table information. Differential Revision: https://reviews.llvm.org/D59490 llvm-svn: 356895
* [perf][DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces"Sylvestre Ledru2019-03-201-4/+10
| | | | | | | | | | | | | | | | Summary: Fix the build failure when perf jit is enabled Reviewers: avl, dblaikie Reviewed By: avl Subscribers: modocache, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59189 llvm-svn: 356542
* Add newline to interpreter debugging outputKristof Beyls2019-03-071-1/+1
| | | | | | | | | | | When running lli --debug --force-interpreter=true the executed instructions are printed but are missing newlines. This commit adds the missing newlines. Patch by Andrew Brown. Differential Revision: https://reviews.llvm.org/D57806 llvm-svn: 355587
* Attempt to fix buildbot after r354972 [#1]. NFCI.Alexey Lapshin2019-02-271-1/+3
| | | | llvm-svn: 355013
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-3/+2
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-011-1/+2
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* Add namespace to some types.Richard Trieu2019-01-313-18/+21
| | | | llvm-svn: 352725
* [RuntimeDyld] Don't try to allocate sections with align 0.Zachary Turner2019-01-301-0/+5
| | | | | | | | | | | | | ELF sections allow 0 for the alignment, which is specified to be the same as 1. However many clients do not expect this and will behave poorly in the presence of a 0-aligned section (for example by trying to modulo something by the section alignment). We can be more polite by making sure that we always pass a non-zero value to clients. Differential Revision: https://reviews.llvm.org/D57482 llvm-svn: 352694
* [RuntimeDyld] load all sections with ProcessAllSectionsYonghong Song2019-01-281-0/+19
| | | | | | | | | | | | | | | | | | | | | | | This patch tried to address the following use case. . bcc (https://github.com/iovisor/bcc) utilizes llvm JIT to compile for BTF target. . with -g, .BTF and .BTF.ext sections (BPF debug info) will be generated by LLVM. . .BTF does not have relocations and .BTF.ext has some relocations. . With ProcessAllSections, .BTF.ext is loaded by JIT dynamic linker and is available to application. But .BTF is not loaded. The bcc application needs both .BTF.ext and .BTF for debugging purpose, and .BTF is not loaded. This patch addressed this issue by iterating over all sections and loading any missing sections, after symbol/relocation processing in loadObjectImpl(). Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D55943 llvm-svn: 352432
* MemoryBlock: Do not automatically extend a given size to a multiple of page ↵Rui Ueyama2019-01-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | | size. Previously, MemoryBlock automatically extends a requested buffer size to a multiple of page size because (I believe) doing it was thought to be harmless and with that you could get more memory (on average 2KiB on 4KiB-page systems) "for free". That programming interface turned out to be error-prone. If you request N bytes, you usually expect that a resulting object returns N for `size()`. That's not the case for MemoryBlock. Looks like there is only one place where we take the advantage of allocating more memory than the requested size. So, with this patch, I simply removed the automatic size expansion feature from MemoryBlock and do it on the caller side when needed. MemoryBlock now always returns a buffer whose size is equal to the requested size. Differential Revision: https://reviews.llvm.org/D56941 llvm-svn: 351916
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1971-284/+213
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Revert r351138 "[ORC] Move ORC Core symbol map and set types into their ownLang Hames2019-01-153-256/+233
| | | | | | | | header: CoreTypes.h." This commit broke some bots. Reverting while I investigate. llvm-svn: 351195
* [ORC] Move ORC Core symbol map and set types into their own header: CoreTypes.h.Lang Hames2019-01-143-233/+256
| | | | | | | This will allow other utilities (including a future RuntimeDyld replacement) to use these types without pulling in the major Core types (JITDylib, etc.). llvm-svn: 351138
* [ORC][MIPS] Fill delay-slot after `jr` instructionSimon Atanasyan2019-01-121-5/+5
| | | | | | | | | | MIPS `jr` instruction uses a delay-slot. To escape execution of arbitrary instruction we should either fill the delay-slot by `nop` instruction or swap `jr` instruction and logically preceding instruction. This fix implements the second method to generate a bit more effective code. llvm-svn: 351001
* [ORC][MIPS] Setup t9 register and call function through this registerSimon Atanasyan2019-01-121-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MIPS ABI states that every function must be called through jalr $t9. In other words, a function expect that t9 register points to the beginning of its code. A function uses this register to calculate offset to the Global Offset Table and save it to the `gp` register. ``` lui $gp, %hi(_gp_disp) addiu $gp, %lo(_gp_disp) addu $gp, $gp, $t9 ``` If `t9` and as a result `$gp` point to the wrong place the following code loads incorrect value from GOT and passes control to invalid code. ``` lw $v0,%call16(foo)($gp) jalr $t9 ``` OrcMips32 and OrcMips64 writeResolverCode methods pass control to the resolved address, but do not setup `$t9` before the call. The `t9` holds value of the beginning of `resolver` code so any attempts to call routines via GOT failed. This change fixes the problem. The `OrcLazy/hidden-visibility.ll` test starts to pass correctly. Before the change it fails on MIPS because the `exitOnLazyCallThroughFailure` called from the resolver code could not call libc routine `exit` via GOT. Differential Revision: http://reviews.llvm.org/D56058 llvm-svn: 351000
* [opaque pointer types] Remove some calls to generic Type subtype accessors.James Y Knight2019-01-102-11/+7
| | | | | | | | | | | | That is, remove many of the calls to Type::getNumContainedTypes(), Type::subtypes(), and Type::getContainedType(N). I'm not intending to remove these accessors -- they are useful/necessary in some cases. However, removing the pointee type from pointers would potentially break some uses, and reducing the number of calls makes it easier to audit. llvm-svn: 350835
* [ORC] Rename register in the OrcMips64 resolver code comments. NFCSimon Atanasyan2018-12-231-2/+2
| | | | | | | The `fp` and `s8` register names are synonyms. But `fp` better reflects a purpose of the register. llvm-svn: 350023
* [ORC] clang-format OrcMips32 and OrcMips64 code. NFCSimon Atanasyan2018-12-231-24/+16
| | | | llvm-svn: 350022
* [ORC] Remove redundant instruction from MIPS resolver code. NFCSimon Atanasyan2018-12-231-8/+7
| | | | | | It's redundant to restore the `$a3` register twice. llvm-svn: 350021
* Implement IMAGE_REL_AMD64_SECREL for RuntimeDyldCOFFX86_64Nathan Lanza2018-12-121-0/+7
| | | | | | | | lldb on Windows uses the ExecutionEngine for expression evaluation and hits the llvm_unreachable due to this relocation. Thus, implement the relocation and add a test to verify it's function. llvm-svn: 348904
* [ExecutionEngine] Change NotifyObjectEmitted/NotifyObjectFreed API.Lang Hames2018-12-047-61/+66
| | | | | | | | | | | | | This patch renames both methods (NotifyObjectEmitted -> notifyObjectLoaded, and NotifyObjectFreed -> notifyObjectFreed), adds an abstract "ObjectKey" (uint64_t) parameter to notifyObjectLoaded, and replaces the ObjectFile parameter for notifyObjectFreed with an ObjectKey. Using an ObjectKey to track identify events, rather than a reference to the ObjectFile, allows us to free the ObjectFile after notifyObjectLoaded is called, saving memory. https://reviews.llvm.org/D53773 llvm-svn: 348223
* [ExecutionEngine][Interpreter] Fix out-of-bounds array access.Lang Hames2018-11-201-1/+2
| | | | | | | | | | If args is empty then accesing element 0 is illegal. https://reviews.llvm.org/D53556 Patch by Eugene Sharygin. Thanks Eugene! llvm-svn: 347281
* [BuildingAJIT] Update chapter 2 to use the ORCv2 APIs.Lang Hames2018-11-131-1/+2
| | | | llvm-svn: 346726
* [Support] Make error banner optional in logAllUnhandledErrorsJonas Devlieghere2018-11-115-7/+7
| | | | | | | | In a lot of places an empty string was passed as the ErrorBanner to logAllUnhandledErrors. This patch makes that argument optional to simplify the call sites. llvm-svn: 346604
* [ORC] Fix hex printing of uint64_t values.Lang Hames2018-10-312-6/+6
| | | | | | | A plain "%x" format string will drop the high 32-bits. Use the PRIx64 macro instead. llvm-svn: 345696
* ADT/STLExtras: Introduce llvm::empty; NFCMatthias Braun2018-10-311-1/+1
| | | | | | | | This is modeled after C++17 std::empty(). Differential Revision: https://reviews.llvm.org/D53909 llvm-svn: 345679
* [ORC] Re-apply r345077 with fixes to remove ambiguity in lookup calls.Lang Hames2018-10-237-83/+113
| | | | llvm-svn: 345098
* Revert r345077 "[ORC] Change how non-exported symbols are matched during ↵Reid Kleckner2018-10-237-112/+84
| | | | | | | | | | | | | | | lookup." Doesn't build on Windows. The call to 'lookup' is ambiguous. Clang and MSVC agree, anyway. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/787 C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): error C2668: 'llvm::orc::ExecutionSession::lookup': ambiguous call to overloaded function C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(823): note: could be 'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(llvm::ArrayRef<llvm::orc::JITDylib *>,llvm::orc::SymbolStringPtr)' C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(817): note: or 'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(const llvm::orc::JITDylibSearchList &,llvm::orc::SymbolStringPtr)' C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): note: while trying to match the argument list '(initializer list, llvm::orc::SymbolStringPtr)' llvm-svn: 345078
* [ORC] Change how non-exported symbols are matched during lookup.Lang Hames2018-10-237-84/+112
| | | | | | | | | | | | | | | | | In the new scheme the client passes a list of (JITDylib&, bool) pairs, rather than a list of JITDylibs. For each JITDylib the boolean indicates whether or not to match against non-exported symbols (true means that they should be found, false means that they should not). The MatchNonExportedInJD and MatchNonExported parameters on lookup are removed. The new scheme is more flexible, and easier to understand. This patch also updates JITDylib search orders to be lists of (JITDylib&, bool) pairs to match the new lookup scheme. Error handling is also plumbed through the LLJIT class to allow regression tests to fail predictably when a lookup from a lazy call-through fails. llvm-svn: 345077
* [RuntimeDyld][COFF] Skip non-loaded sections when calculating ImageBase.Lang Hames2018-10-231-1/+7
| | | | | | | | | | | | | | | | | | Non-loaded sections (whose unused load-address defaults to zero) should not be taken into account when calculating ImageBase, or ImageBase will be incorrectly set to 0. Patch by Andrew Scheidecker. Thanks Andrew! https://reviews.llvm.org/D51343 + // The Sections list may contain sections that weren't loaded for + // whatever reason: they may be debug sections, and ProcessAllSections + // is false, or they may be sections that contain 0 bytes. If the + // section isn't loaded, the load address will be 0, and it should not + // be included in the ImageBase calculation. llvm-svn: 344995
* [ORC] Show JITDylib search order in JITDylib::dump.Lang Hames2018-10-231-0/+4
| | | | | | This can be helpful in debugging search-order related failures. llvm-svn: 344994
* [ORC] Dump flags for JITDylib symbol table entries.Lang Hames2018-10-231-2/+2
| | | | | | This can help when debugging flag-specific symbol table issues. llvm-svn: 344993
* [ORC] Guard access to the MemMgrs vector in RTDyldObjectLinkingLayer.Lang Hames2018-10-221-3/+10
| | | | | | | | | Otherwise we can end up with a data-race when linking concurrently. This should fix an intermittent failure in the multiple-compile-threads-basic.ll testcase. llvm-svn: 344956
* [ORC] Make the VModuleKey optional, propagate it via MaterializationUnit andLang Hames2018-10-1610-71/+70
| | | | | | | | | | | | | | | | | | | | | | MaterializationResponsibility. VModuleKeys are intended to enable selective removal of modules from a JIT session, however for a wide variety of use cases selective removal is not needed and introduces unnecessary overhead. As of this commit, the default constructed VModuleKey value is reserved as a "do not track" value, and becomes the default when adding a new module to the JIT. This commit also changes the propagation of VModuleKeys. They were passed alongside the MaterializationResponsibity instance in XXLayer::emit methods, but are now propagated as part of the MaterializationResponsibility instance itself (and as part of MaterializationUnit when stored in a JITDylib). Associating VModuleKeys with MaterializationUnits in this way should allow for a thread-safe module removal mechanism in the future, even when a module is in the process of being compiled, by having the MaterializationResponsibility object check in on its VModuleKey's state before commiting its results to the JITDylib. llvm-svn: 344643
* [ORC] Rename ORC layers to make the "new" ORC layers the default.Lang Hames2018-10-1510-44/+44
| | | | | | | | | | | | | This commit adds a 'Legacy' prefix to old ORC layers and utilities, and removes the '2' suffix from the new ORC layers. If you wish to continue using the old ORC layers you will need to add a 'Legacy' prefix to your classes. If you were already using the new ORC layers you will need to drop the '2' suffix. The legacy layers will remain in-tree until the new layers reach feature parity with them. This will involve adding support for removing code from the new layers, and ensuring that performance is comperable. llvm-svn: 344572
* [ORC] Rename MultiThreadedSimpleCompiler to ConcurrentIRCompiler.Lang Hames2018-10-151-1/+1
| | | | | | | | | | | The new name is a better fit: This class does not actually spawn any new threads for compilation, it is just safe to call from multiple threads concurrently. The "Simple" part of the name did not convey much either, so it was dropped. llvm-svn: 344567
* [ORC] Switch to DenseMap/DenseSet for ORC symbol map/set types.Lang Hames2018-10-152-29/+38
| | | | llvm-svn: 344565
* [ORC] Simplify naming for JITDylib definition generators.Lang Hames2018-10-152-33/+36
| | | | | | | | | Renames: JITDylib's setFallbackDefinitionGenerator method to setGenerator. DynamicLibraryFallbackGenerator class to DynamicLibrarySearchGenerator. ReexportsFallbackDefinitionGenerator to ReexportsGenerator. llvm-svn: 344489
* [ORC] During lookup, do not match against hidden symbols in other JITDylibs.Lang Hames2018-10-136-46/+64
| | | | | | | | | | | | This adds two arguments to the main ExecutionSession::lookup method: MatchNonExportedInJD, and MatchNonExported. These control whether and where hidden symbols should be matched when searching a list of JITDylibs. A similar effect could have been achieved by filtering search results, but this would have involved materializing symbol definitions (since materialization is triggered on lookup) only to throw the results away, among other issues. llvm-svn: 344467
* [ORC] Promote and rename private symbols inside the CompileOnDemand layer,Lang Hames2018-10-094-8/+38
| | | | | | | | | | | | | | | rather than require them to have been promoted before being passed in. Dropping this precondition is better for layer composition (CompileOnDemandLayer was the only one that placed pre-conditions on the modules that could be added). It also means that the promoted private symbols do not show up in the target JITDylib's symbol table. Instead, they are confined to the hidden implementation dylib that contains the actual definitions. For the 403.gcc testcase this cut down the public symbol table size from ~15,000 symbols to ~4000, substantially reducing symbol dependence tracking costs. llvm-svn: 344078
* [ORC] Add a 'remove' method to JITDylib to remove symbols.Lang Hames2018-10-061-0/+68
| | | | | | | | Symbols can be removed provided that all are present in the JITDylib and none are currently in the materializing state. On success all requested symbols are removed. On failure an error is returned and no symbols are removed. llvm-svn: 343928
* [ORC] Pass symbol name to discard by const reference.Lang Hames2018-10-065-7/+8
| | | | | | This saves some unnecessary atomic ref-counting operations. llvm-svn: 343927
* [ORC] Pass Symbols to ExecutionSession::lookup by value, potentially saving aLang Hames2018-10-011-2/+2
| | | | | | copy. llvm-svn: 343442
* [ORC] Add convenience methods for creating DynamicLibraryFallbackGenerators forLang Hames2018-10-011-0/+9
| | | | | | | | libraries on disk, and for the current process. Avoids more boilerplate during JIT construction. llvm-svn: 343430
OpenPOWER on IntegriCloud