summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h
Commit message (Collapse)AuthorAgeFilesLines
* [Orc] Address the remaining move-capture FIXMEsBenjamin Kramer2019-09-131-1/+1
| | | | | | | This required spreading unique_function a bit more, which I think is a good thing. llvm-svn: 371843
* Simplify decoupling between RuntimeDyld/RuntimeDyldChecker, add 'got_addr' util.Lang Hames2019-04-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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-17/+29
| | | | | | | This will allow RuntimeDyldChecker (and rtdyld-check tests) to test a new JIT linker: JITLink (https://reviews.llvm.org/D58704). llvm-svn: 357947
* 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-0/+6
| | | | | | | | | | | | | | | | | 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
* [ORC] Reapply r342939 with a fix for MSVC's promise/future restrictions.Lang Hames2018-09-251-0/+3
| | | | llvm-svn: 343012
* Revert "[ORC] Switch to asynchronous resolution in JITSymbolResolver."Lang Hames2018-09-251-3/+0
| | | | | | | | | 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-0/+3
| | | | | | | | | | | | | | | | | | | 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] Add a 'Callable' flag to JITSymbolFlags.Lang Hames2018-08-011-1/+1
| | | | | | | | | | | | | 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
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-011-1/+1
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-19/+19
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [ExecutionEngine] Add a getSymbolTable method to RuntimeDyld.Lang Hames2018-03-141-0/+15
| | | | | | | | | | 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] Re-apply r322913 with a fix for a read-after-free error.Lang Hames2018-01-191-1/+2
| | | | | | | 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-2/+1
| | | | llvm-svn: 322914
* [ORC] Redesign the JITSymbolResolver interface to support bulk queries.Lang Hames2018-01-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [RuntimeDyld][ORC] Add support for Thumb mode to RuntimeDyldMachOARM.Lang Hames2017-08-091-8/+30
| | | | | | | | | | | 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-1/+1
| | | | | | | | 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
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* RuntimeDyldELF/AArch64: Implement basic GOT supportEugene Leviant2017-02-061-1/+12
| | | | | | | | | 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][mcjit] Add the majority of N32 support.Simon Dardis2016-10-201-0/+2
| | | | | | | | | The missing piece is relocation composition for %hi(%neg(%gp_rel(x))) and similar. Patch by: Daniel Sanders llvm-svn: 284724
* Handle relocations to thumb functions when dynamic linking COFF modulesWalter Erquinigo2016-10-171-4/+19
| | | | | | | | | | | | | | | | Summary: This adds the necessary logic to support relocations to thumb functions in the COFF dynamic linker. The jumps to function addresses are mostly blx, which requires the ISA selection bit when jumping to a thumb function. Note: I'm determining if the relocation requires the ISA bit when creating the relocation entries and not when resolving the relocation. I have to do that because I need the ObjectFile and the actual Symbol, which are available only when creating the entries. It would require a gross refactor if I do it otherwise, but I'm okay with doing it if you think it's better. Reviewers: peter.smith, compnerd Subscribers: rengolin, sas Differential Revision: https://reviews.llvm.org/D25151 llvm-svn: 284410
* [ExecutionEngine] Refactor - Roll JITSymbolFlags functionality into JITSymbol.hLang Hames2016-08-041-3/+6
| | | | | | and remove the JITSymbolFlags header. llvm-svn: 277766
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-4/+4
| | | | | | | | | | | | | | | | 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
* [RuntimeDyld] Plumb Error/Expected through the internals of RuntimeDyld.Lang Hames2016-04-271-37/+22
| | | | | | | | | | | | | 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
* Thread Expected<...> up from libObject’s getName() for symbols to allow ↵Kevin Enderby2016-04-201-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Header cleanupMehdi Amini2016-04-181-2/+0
| | | | | | | | | | | | | | 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
* [RuntimeDyld] Add alignment arguments to the reserveAllocationSpace method ofLang Hames2016-01-101-2/+4
| | | | | | | | | | | | | | RuntimeDyld::MemoryManager. The RuntimeDyld::MemoryManager::reserveAllocationSpace method is called when object files are loaded, and gives clients a chance to pre-allocate memory for all segments. Previously only the size of each segment (code, ro-data, rw-data) was supplied but not the alignment. This hasn't caused any problems so far, as most clients allocate via the MemoryBlock interface which returns page-aligned blocks. Adding alignment arguments enables finer grained allocation while still satisfying alignment restrictions. llvm-svn: 257294
* [RuntimeDyld] DenseMap -> std::unordered_mapKeno Fischer2015-12-031-1/+2
| | | | | | | | | | | DenseMap is most applicable when both keys and values are small. In this case, the value violates that assumption, causing quite significant memory overhead. A std::unordered_map is more appropriate in this case (or at least fixed the memory problems I was seeing). Differential Revision: http://reviews.llvm.org/D14910 llvm-svn: 254651
* [RuntimeDyld] Avoid unused-private-field warning; NFCSanjoy Das2015-11-231-1/+5
| | | | | | Fixes the no asserts -Werror,-Wunused-private-field build. llvm-svn: 253933
* [RuntimeDyld] Don't allocate unnecessary stub buffer spaceSanjoy Das2015-11-231-0/+5
| | | | | | | | | | | | | | Summary: For relocation types that are known to not require stub functions, there is no need to allocate extra space for the stub functions. Reviewers: lhames, reames, maksfb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14676 llvm-svn: 253920
* [RuntimeDyld] Add bounds checking to SectionEntry::advanceStubOffsetSanjoy Das2015-11-231-3/+12
| | | | | | | | | | | | | | Summary: Change SectionEntry to keep track of the size of its underlying allocation, and use that to bounds check advanceStubOffset. Reviewers: lhames, andrew.w.kaylor, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14675 llvm-svn: 253919
* [RuntimeDyld] Add accessors to `SectionEntry`; NFCSanjoy Das2015-11-231-3/+28
| | | | | | | | | | | | | | | | Summary: Remove naked access to the data members in `SectionEntry` and route accesses through accessor functions. This makes it obvious how the instances of the class are used, and will also facilitate adding bounds checking to `advanceStubOffset` in a later change. Reviewers: lhames, loladiro, andrew.w.kaylor Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14674 llvm-svn: 253918
* [RuntimeDyld] Add support for absolute symbols.Lang Hames2015-10-181-2/+9
| | | | llvm-svn: 250639
* [RuntimeDyld] Make LoadedObjectInfo::getLoadedSectionAddress take a SectionRefLang Hames2015-07-281-1/+1
| | | | | | rather than a string section name. llvm-svn: 243456
* [Mips64] Add support for MCJIT for MIPS64r2 and MIPS64r6Petar Jovanovic2015-05-281-0/+7
| | | | | | | | | | Add support for resolving MIPS64r2 and MIPS64r6 relocations in MCJIT. Patch by Vladimir Radosavljevic. Differential Revision: http://reviews.llvm.org/D9667 llvm-svn: 238424
* Make it easier to use DwarfContext with MCJITKeno Fischer2015-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This supersedes http://reviews.llvm.org/D4010, hopefully properly dealing with the JIT case and also adds an actual test case. DwarfContext was basically already usable for the JIT (and back when we were overwriting ELF files it actually worked out of the box by accident), but in order to resolve relocations correctly it needs to know the load address of the section. Rather than trying to get this out of the ObjectFile or requiring the user to create a new ObjectFile just to get some debug info, this adds the capability to pass in that info directly. As part of this I separated out part of the LoadedObjectInfo struct from RuntimeDyld, since it is now required at a higher layer. Reviewers: lhames, echristo Reviewed By: echristo Subscribers: vtjnash, friss, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D6961 llvm-svn: 237961
* [RuntimeDyld] Make SectionEntry's Name field a std::string.Lang Hames2015-04-141-1/+1
| | | | | | | StringRef is unsafe here, since SectionEntry instances can outlive the ObjectFile instances they are created from. llvm-svn: 234910
* [RuntimeDyldELF] Improve GOT supportKeno Fischer2015-04-141-4/+0
| | | | | | | | | | | | | | | | | | Summary: This is the first in a series of patches to eventually add support for TLS relocations to RuntimeDyld. This patch resolves an issue in the current GOT handling, where GOT entries would be reused between object files, which leads to the same situation that necessitates the GOT in the first place, i.e. that the 32-bit offset can not cover all of the address space. Thus this patch makes the GOT object-file-local. Unfortunately, this still isn't quite enough, because the MemoryManager does not yet guarantee that sections are allocated sufficiently close to each other, even if they belong to the same object file. To address this concern, this patch also adds a small API abstraction on top of the GOT allocation mechanism that will allow (temporarily, until the MemoryManager is improved) using the stub mechanism instead of allocating a different section. The actual switch from separate section to stub mechanism will be part of a follow-on commit, so that it can be easily reverted independently at the appropriate time. Test Plan: Includes a test case where the GOT of two object files is artificially forced to be apart by several GB. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8813 llvm-svn: 234839
* [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames2015-03-301-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-26/+15
| | | | | | Dave Blaikie. Thanks Dave! llvm-svn: 231896
* Temporarily revert r231726 and r231724 as they're breaking the build.:Eric Christopher2015-03-101-15/+26
| | | | | | | | | | | | | | | | | | | 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-26/+15
| | | | | | | | | | 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
* Fix unused variable/function warningsDavid Majnemer2015-03-071-7/+5
| | | | llvm-svn: 231576
* ExecutionEngine: Preliminary support for dynamically loadable coff objectsDavid Majnemer2015-03-071-0/+10
| | | | | | | | | | Provide basic support for dynamically loadable coff objects. Only handles a subset of x64 currently. Patch by Andy Ayers! Differential Revision: http://reviews.llvm.org/D7793 llvm-svn: 231574
* Revert r227247 and r227228: "Add weak symbol support to RuntimeDyld".Lang Hames2015-01-281-3/+0
| | | | | | | | | This has wider implications than I expected when I reviewed the patch: It can cause JIT crashes where clients have used the default value for AbortOnFailure during symbol lookup. I'm currently investigating alternative approaches and I hope to have this back in tree soon. llvm-svn: 227287
* [ExecutionEngine] Add weak symbol support to RuntimeDyldKeno Fischer2015-01-271-0/+3
| | | | | | | | | | | Support weak symbols by first looking up if there is an externally visible symbol we can find, and only if that fails using the one in the object file we're loading. Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6950 llvm-svn: 227228
* [RuntimeDyld] Tidy up emitCommonSymbols a little. NFC.Lang Hames2015-01-171-6/+2
| | | | llvm-svn: 226358
* [RuntimeDyld] Track symbol visibility in RuntimeDyld.Lang Hames2015-01-161-12/+41
| | | | | | | | | | | | | | | | | | | RuntimeDyld symbol info previously consisted of just a Section/Offset pair. This patch replaces that pair type with a SymbolInfo class that also tracks symbol visibility. A new method, RuntimeDyld::getExportedSymbolLoadAddress, is introduced which only returns a non-zero result for exported symbols. For non-exported or non-existant symbols this method will return zero. The RuntimeDyld::getSymbolAddress method retains its current behavior, returning non-zero results for all symbols regardless of visibility. No in-tree clients of RuntimeDyld are changed. The newly introduced functionality will be used by the Orc APIs. No test case: Since this patch doesn't modify the behavior for any in-tree clients we don't have a good tool to test this with yet. Once Orc is in we can use it to write regression tests that test these changes. llvm-svn: 226341
* [MCJIT] Remove the local symbol table from RuntimeDlyd - it's not needed.Lang Hames2014-11-271-1/+1
| | | | | | | | All symbols have to be stored in the global symbol to enable cross-rtdyld-instance linking, so the local symbol table content is redundant. llvm-svn: 222867
OpenPOWER on IntegriCloud