summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Simplify decoupling between RuntimeDyld/RuntimeDyldChecker, add 'got_addr' util.Lang Hames2019-04-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [RuntimeDyld] Decouple RuntimeDyldChecker from RuntimeDyld.Lang Hames2019-04-081-26/+60
| | | | | | | This will allow RuntimeDyldChecker (and rtdyld-check tests) to test a new JIT linker: JITLink (https://reviews.llvm.org/D58704). llvm-svn: 357947
* [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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [ORC] Add an asynchronous jit-link function, jitLinkForORC, to RuntimeDyld andLang Hames2018-09-251-4/+88
| | | | | | | | | | | | | | | | | switch RTDyldObjectLinkingLayer2 to use it. RuntimeDyld::loadObject is currently a blocking operation. This means that any JIT'd code whose call-graph contains an embedded complete K graph will require at least K threads to link, which precludes the use of a fixed sized thread pool for concurrent JITing of arbitrary code (whatever K the thread-pool is set at, any code with a K+1 complete subgraph will deadlock at JIT-link time). To address this issue, this commmit introduces a function called jitLinkForORC that uses continuation-passing style to pass the fix-up and finalization steps to the asynchronous symbol resolver interface so that linking can be performed without blocking. llvm-svn: 343043
* Remove 'orc' namespace from MSVCErrorWorkarounds.h, fix some typos that wereLang Hames2018-09-251-1/+1
| | | | | | | | | breaking windows builds. The 'orc' namespace was accidentally left in when the workarounds were moved out of orc in r343011. llvm-svn: 343025
* Fix a missing includes and a use of the MSVC promise/future workaround thatLang Hames2018-09-251-0/+1
| | | | | | were left out of r343011/r343012. llvm-svn: 343022
* [ORC] Reapply r342939 with a fix for MSVC's promise/future restrictions.Lang Hames2018-09-251-36/+58
| | | | llvm-svn: 343012
* Revert "[ORC] Switch to asynchronous resolution in JITSymbolResolver."Lang Hames2018-09-251-52/+36
| | | | | | | | | This reverts commit r342939. MSVC's promise/future implementation does not like types that are not default constructible. Reverting while I figure out a solution. llvm-svn: 342941
* [ORC] Switch to asynchronous resolution in JITSymbolResolver.Lang Hames2018-09-251-36/+52
| | | | | | | | | | | | | | | | | | | Asynchronous resolution (where the caller receives a callback once the requested set of symbols are resolved) is a core part of the new concurrent ORC APIs. This change extends the asynchronous resolution model down to RuntimeDyld, which is necessary to prevent deadlocks when compiling/linking on a fixed number of threads: If RuntimeDyld's linking process were a blocking operation, then any complete K-graph in a program will require at least K threads to link in the worst case, as each thread would block waiting for all the others to complete. Using callbacks instead allows the work to be passed between dependent threads until it is complete. For backwards compatibility, all existing RuntimeDyld functions will continue to operate in blocking mode as before. This change will enable the introduction of a new async finalization process in a subsequent patch to enable asynchronous JIT linking. llvm-svn: 342939
* [ORC] Replace lookupFlags in JITSymbolResolver with getResponsibilitySet.Lang Hames2018-08-281-23/+20
| | | | | | | | | | | | | | The new method name/behavior more closely models the way it was being used. It also fixes an assertion that can occur when using the new ORC Core APIs, where flags alone don't necessarily provide enough context to decide whether the caller is responsible for materializing a given symbol (which was always the reason this API existed). The default implementation of getResponsibilitySet uses lookupFlags to determine responsibility as before, so existing JITSymbolResolvers should continue to work. llvm-svn: 340874
* [RuntimeDyld] Fix a bug in RuntimeDyld::loadObjectImpl that was over-allocatingLang Hames2018-08-181-1/+1
| | | | | | | | | | space for common symbols. Patch by Dmitry Sidorov. Thanks Dmitry! Differential revision: https://reviews.llvm.org/D50240 llvm-svn: 340125
* [ORC] Add a 'Callable' flag to JITSymbolFlags.Lang Hames2018-08-011-13/+20
| | | | | | | | | | | | | The callable flag can be used to indicate that a symbol is callable. If present, the symbol is callable. If absent, the symbol may or may not be callable (the client must determine this by context, for example by examining the program representation that will provide the symbol definition). This flag will be used in the near future to enable creation of lazy compilation stubs based on SymbolFlagsMap instances only (without having to provide additional information to determine which symbols need stubs). llvm-svn: 338649
* [RuntimeDyld] Add an assert to catch misbehaving symbol resolvers.Lang Hames2018-06-121-0/+3
| | | | | | | | | Resolvers are required to find results for all requested symbols or return an error, but if a resolver fails to adhere to this contract (by returning results for only a subset of the requested symbols) then this code will infinite loop. This assertion catches resolvers that fail to adhere to the contract. llvm-svn: 334536
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-43/+41
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [RuntimeDyld] Silence a compiler error.Lang Hames2018-03-141-1/+1
| | | | | | | This should fix the error at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/19008 llvm-svn: 327478
* [ExecutionEngine] Add a getSymbolTable method to RuntimeDyld.Lang Hames2018-03-141-0/+6
| | | | | | | | | | This can be used to extract the symbol table from a RuntimeDyld instance prior to disposing of it. This patch also updates RTDyldObjectLinkingLayer to use the new method, rather than requesting symbols one at a time via getSymbol. llvm-svn: 327476
* [ORC] Add orc::SymbolResolver, a Orc/Legacy API interop header, and anLang Hames2018-01-221-3/+3
| | | | | | | | | | | | | | | orc::SymbolResolver to JITSymbolResolver adapter. The new orc::SymbolResolver interface uses asynchronous queries for better performance. (Asynchronous queries with bulk lookup minimize RPC/IPC overhead, support parallel incoming queries, and expose more available work for distribution). Existing ORC layers will soon be updated to use the orc::SymbolResolver API rather than the legacy llvm::JITSymbolResolver API. Because RuntimeDyld still uses JITSymbolResolver, this patch also includes an adapter that wraps an orc::SymbolResolver with a JITSymbolResolver API. llvm-svn: 323073
* Fix -Wunused-variable.Rui Ueyama2018-01-191-1/+0
| | | | llvm-svn: 323004
* [ORC] Re-apply r322913 with a fix for a read-after-free error.Lang Hames2018-01-191-145/+159
| | | | | | | ExternalSymbolMap now stores the string key (rather than using a StringRef), as the object file backing the key may be removed at any time. llvm-svn: 323001
* [ORC] Revert r322913 while I investigate an ASan failure.Lang Hames2018-01-191-159/+145
| | | | llvm-svn: 322914
* [ORC] Redesign the JITSymbolResolver interface to support bulk queries.Lang Hames2018-01-191-145/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bulk queries reduce IPC/RPC overhead for cross-process JITing and expose opportunities for parallel compilation. The two new query methods are lookupFlags, which finds the flags for each of a set of symbols; and lookup, which finds the address and flags for each of a set of symbols. (See doxygen comments for more details.) The existing JITSymbolResolver class is renamed LegacyJITSymbolResolver, and modified to extend the new JITSymbolResolver class using the following scheme: - lookupFlags is implemented by calling findSymbolInLogicalDylib for each of the symbols, then returning the result of calling getFlags() on each of these symbols. (Importantly: lookupFlags does NOT call getAddress on the returned symbols, so lookupFlags will never trigger materialization, and lookupFlags will never call findSymbol, so only symbols that are part of the logical dylib will return results.) - lookup is implemented by calling findSymbolInLogicalDylib for each symbol and falling back to findSymbol if findSymbolInLogicalDylib returns a null result. Assuming a symbol is found its getAddress method is called to materialize it and the result (if getAddress succeeds) is stored in the result map, or the error (if getAddress fails) is returned immediately from lookup. If any symbol is not found then lookup returns immediately with an error. This change will break any out-of-tree derivatives of JITSymbolResolver. This can be fixed by updating those classes to derive from LegacyJITSymbolResolver instead. llvm-svn: 322913
* [ExecutionEngine] Rename JITSymbol::isStrongDefinition to isStrong.Lang Hames2018-01-161-1/+1
| | | | | | For symmetry with isWeak, isCommon. llvm-svn: 322594
* [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in RuntimeDyld.Nitesh Jain2017-10-221-6/+32
| | | | | | | | | | Reviewers: sdardis Subscribers: jaydeep, bhushan, llvm-commits Differential Revision: https://reviews.llvm.org/D38314 llvm-svn: 316287
* [RuntimeDyld][ORC] Add support for Thumb mode to RuntimeDyldMachOARM.Lang Hames2017-08-091-9/+31
| | | | | | | | | | | This patch adds support for thumb relocations to RuntimeDyldMachOARM, and adds a target-specific flags field to JITSymbolFlags (so that on ARM we can record whether each symbol is Thumb-mode code). RuntimeDyldImpl::emitSection is modified to ensure that stubs memory is correctly aligned based on the size returned by getStubAlignment(). llvm-svn: 310517
* [ORC] Errorize the ORC APIs.Lang Hames2017-07-071-6/+27
| | | | | | | | This patch updates the ORC layers and utilities to return and propagate llvm::Errors where appropriate. This is necessary to allow ORC to safely handle error cases in cross-process and remote JITing. llvm-svn: 307350
* Revert [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in ↵Sagar Thakur2017-06-221-32/+6
| | | | | | | | RuntimeDyld Reverting due to build bot failures llvm-svn: 306000
* [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in RuntimeDyldSagar Thakur2017-06-221-6/+32
| | | | | | | | | After the N64 static relocation model support was added to llvm it is required to add its support in RuntimeDyld also because lldb uses ExecutionEngine for evaluating expressions. Reviewed by sdardis Differential: D31649 llvm-svn: 305997
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [RuntimeDyld] Fix debug section relocation (pr20457)Pavel Labath2017-05-171-3/+7
| | | | | | | | | | | | | | | | | | Summary: Debug info sections, (or non-SHF_ALLOC sections in general) should be linked as if their load address was zero to emulate the behavior of the static linker. This bug was discovered because it was breaking lldb expression evaluation on linux. Reviewers: lhames Subscribers: aprantl, eugene, clayborg, lldb-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D32899 llvm-svn: 303239
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames. RuntimeDyld was previously responsible for tracking allocated EH frames, but it makes more sense to have the RuntimeDyld::MemoryManager track them (since the frames are allocated through the memory manager, and written to memory owned by the memory manager). This patch moves the frame tracking into RTDyldMemoryManager, and changes the deregisterFrames method on RuntimeDyld::MemoryManager from: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size); to: void deregisterEHFrames(); Separating this responsibility will allow ORC to continue to throw the RuntimeDyld instances away post-link (saving a few dozen bytes per lazy function) while properly deregistering frames when modules are unloaded. This patch also updates ORC to call deregisterEHFrames when modules are unloaded. This fixes a bug where an exception that tears down the JIT can then unwind through dangling EH frames that have been deallocated but not deregistered, resulting in UB. For people using SectionMemoryManager this should be pretty much a no-op. For people with custom allocators that override registerEHFrames/deregisterEHFrames, you will now be responsible for tracking allocated EH frames. Reviewed in https://reviews.llvm.org/D32829 llvm-svn: 302589
* [RuntimeDyld] Make RuntimeDyld honor the ProcessAllSections flag.Lang Hames2017-04-041-2/+2
| | | | | | | | | | | | | | | When the ProcessAllSections flag (introduced in r204398) is set RuntimeDyld is supposed to make a call to the client's memory manager for every section in each object that is loaded. Due to some missing checks, this was not happening in all cases. This patch adds the missing cases, and fixes the Orc unit test that verifies correct behavior for ProcessAllSections (The unit test had been silently bailing out due to an ordering issue: a change in the test order meant that this unit-test was running before the native target was registered. This issue has also been fixed in this patch). This fixes <rdar://problem/22789965> llvm-svn: 299449
* RuntimeDyldELF/AArch64: Implement basic GOT supportEugene Leviant2017-02-061-0/+26
| | | | | | | | | This patch implements two GOT relocations: R_AARCH64_ADR_GOT_PAGE and R_AARCH64_LD64_GOT_LO12_NC Differential revision: https://reviews.llvm.org/D28571 llvm-svn: 294191
* [mips][rtdyld] Move MIPS relocation resolution to a subclass and implement ↵Simon Dardis2016-12-131-3/+6
| | | | | | | | | | | | | | | N32 relocations N32 relocations are only correct for individual relocations at the moment. Support for relocation composition will follow in a later patch. Patch By: Daniel Sanders Reviwers: vkalintiris, atanasyan Differential Revision: https://reviews.llvm.org/D27467 llvm-svn: 289532
* [RuntimeDyld] Skip undefined symbols when building the symbol table.Lang Hames2016-11-301-0/+4
| | | | | | Storing these in the symbol table (with zero values) is just wasted space. llvm-svn: 288225
* Remove LLVM_NOEXCEPT and replace it with noexceptReid Kleckner2016-10-191-1/+1
| | | | | | | Now that we have dropped MSVC 2013, all supported compilers support noexcept and we can drop this portability macro. llvm-svn: 284672
* Re-apply r278065 (Weak symbol support in RuntimeDyld) with a fix for ELF.Lang Hames2016-08-091-0/+18
| | | | llvm-svn: 278149
* Revert r278065 while I investigate some build-bot breakage.Lang Hames2016-08-081-18/+0
| | | | llvm-svn: 278069
* [RuntimeDyld][Orc][MCJIT] Add partial weak-symbol support to RuntimeDyld.Lang Hames2016-08-081-0/+18
| | | | | | | | | | | | | | | This patch causes RuntimeDyld to check for existing definitions when it encounters weak symbols. If a definition already exists then the new weak definition is discarded. All symbol lookups within a "logical dylib" should now agree on the address of any given weak symbol. This allows the JIT to better match the behavior of the static linker for C++ code. This support is only partial, as it does not allow strong definitions that occur after the first weak definition (in JIT symbol lookup order) to override the previous weak definitions. Support for this will be added in a future patch. llvm-svn: 278065
* [RuntimeDyld] Remove symbol that is unused as of r277943.Lang Hames2016-08-071-1/+0
| | | | llvm-svn: 277944
* [RuntimeDyld] Replace manual flag checks with JITSymbolFlags::fromObjectSymbol.Lang Hames2016-08-071-13/+5
| | | | llvm-svn: 277943
* [ExecutionEngine] Refactor - Roll JITSymbolFlags functionality into JITSymbol.hLang Hames2016-08-041-1/+1
| | | | | | and remove the JITSymbolFlags header. llvm-svn: 277766
* [Orc] Fix common symbol support in ORC.Lang Hames2016-08-011-2/+8
| | | | | | | | | | | | | Common symbol support in ORC was broken in r270716 when the symbol resolution rules in RuntimeDyld were changed. With the switch to lazily materialized symbols in r277386, common symbols can be supported by having RuntimeDyld::emitCommonSymbols search for (but not materialize!) definitions elsewhere in the logical dylib. This patch adds the 'Common' flag to JITSymbolFlags, and the necessary check to RuntimeDyld::emitCommonSymbols. llvm-svn: 277397
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-8/+8
| | | | | | | | | | | | | | | | This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
* [LLVM][MIPS] Fix createStubFunction to emit JR encoding based on Arch.Nitesh Jain2016-07-151-1/+4
| | | | | | | | | | Reviewers: vkalintiris, dsanders Subscribers: jaydeep, bhushan, mohit.bhakkad, slthakur, llvm-commits Differential Revision: https://reviews.llvm.org/D21172 llvm-svn: 275559
* 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
OpenPOWER on IntegriCloud