summaryrefslogtreecommitdiffstats
path: root/llvm/test/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Add support for emulated TLS to ORCv2.Lang Hames2020-01-291-0/+23
| | | | | | | | | | | | | | | | | | | | | | | This commit adds a ManglingOptions struct to IRMaterializationUnit, and replaces IRCompileLayer::CompileFunction with a new IRCompileLayer::IRCompiler class. The ManglingOptions struct defines the emulated-TLS state (via a bool member, EmulatedTLS, which is true if emulated-TLS is enabled and false otherwise). The IRCompileLayer::IRCompiler class wraps an IRCompiler (the same way that the CompileFunction typedef used to), but adds a method to return the IRCompileLayer::ManglingOptions that the compiler will use. These changes allow us to correctly determine the symbols that will be produced when a thread local global variable defined at the IR level is compiled with or without emulated TLS. This is required for ORCv2, where MaterializationUnits must declare their interface up-front. Most ORCv2 clients should not require any changes. Clients writing custom IR compilers will need to wrap their compiler in an IRCompileLayer::IRCompiler, rather than an IRCompileLayer::CompileFunction, however this should be a straightforward change (see modifications to CompileUtils.* in this patch for an example). (cherry picked from commit ce2207abaf9a925b35f15ef92aaff6b301ba6d22)
* [ORC] Fix argv handling in runAsMain / lli.Lang Hames2020-01-111-0/+81
| | | | | | | | This fixes an off-by-one error in the argc value computed by runAsMain, and switches lli back to using the input bitcode (rather than the string "lli") as the effective program name. Thanks to Stefan Graenitz for spotting the bug.
* [JITLink][MachO] Fix common symbol size plumbing.Lang Hames2019-12-191-0/+5
| | | | This fixes the underlying bug that was exposed by 298e183e813.
* [ORC][JITLink] Add support for weak references, and improve handling of staticLang Hames2019-11-281-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libraries. This patch substantially updates ORCv2's lookup API in order to support weak references, and to better support static archives. Key changes: -- Each symbol being looked for is now associated with a SymbolLookupFlags value. If the associated value is SymbolLookupFlags::RequiredSymbol then the symbol must be defined in one of the JITDylibs being searched (or be able to be generated in one of these JITDylibs via an attached definition generator) or the lookup will fail with an error. If the associated value is SymbolLookupFlags::WeaklyReferencedSymbol then the symbol is permitted to be undefined, in which case it will simply not appear in the resulting SymbolMap if the rest of the lookup succeeds. Since lookup now requires these flags for each symbol, the lookup method now takes an instance of a new SymbolLookupSet type rather than a SymbolNameSet. SymbolLookupSet is a vector-backed set of (name, flags) pairs. Clients are responsible for ensuring that the set property (i.e. unique elements) holds, though this is usually simple and SymbolLookupSet provides convenience methods to support this. -- Lookups now have an associated LookupKind value, which is either LookupKind::Static or LookupKind::DLSym. Definition generators can inspect the lookup kind when determining whether or not to generate new definitions. The StaticLibraryDefinitionGenerator is updated to only pull in new objects from the archive if the lookup kind is Static. This allows lookup to be re-used to emulate dlsym for JIT'd symbols without pulling in new objects from archives (which would not happen in a normal dlsym call). -- JITLink is updated to allow externals to be assigned weak linkage, and weak externals now use the SymbolLookupFlags::WeaklyReferencedSymbol value for lookups. Unresolved weak references will be assigned the default value of zero. Since this patch was modifying the lookup API anyway, it alo replaces all of the "MatchNonExported" boolean arguments with a "JITDylibLookupFlags" enum for readability. If a JITDylib's associated value is JITDylibLookupFlags::MatchExportedSymbolsOnly then the lookup will only match against exported (non-hidden) symbols in that JITDylib. If a JITDylib's associated value is JITDylibLookupFlags::MatchAllSymbols then the lookup will match against any symbol defined in the JITDylib.
* [JITLink] Make sure MachO/x86-64 handles 32-bit signed addends correctly.Lang Hames2019-11-271-12/+23
| | | | These need to be sign extended when loading into Edge addends.
* ExecutionEngine: add preliminary support for COFF ARM64Adam Kallai2019-11-201-0/+152
| | | | Differential Revision: https://reviews.llvm.org/D69434
* [JITLink] Refactor EH-frame handling to support eh-frames with existing relocs.Lang Hames2019-11-062-0/+4
| | | | | | | | | | | | | | | | | | Some targets (E.g. MachO/arm64) use relocations to fix some CFI record fields in the eh-frame section. When relocations are used the initial (pre-relocation) content of the eh-frame section can no longer be interpreted by following the eh-frame specification. This causes errors in the existing eh-frame parser. This patch moves eh-frame handling into two LinkGraph passes that are run after relocations have been parsed (but before they are applied). The first] pass breaks up blocks in the eh-frame section into per-CFI-record blocks, and the second parses blocks of (potentially multiple) CFI records and adds the appropriate edges to any CFI fields that do not have existing relocations. These passes can be run independently of one another. By handling eh-frame splitting/fixing with LinkGraph passes we can both re-use existing relocations for CFI record fields and avoid applying eh-frame fixups before parsing the section (which would complicate the linker and require extra temporary allocations of working memory).
* [JITLink] Switch to slab allocation for InProcessMemoryManager, re-enable test.Lang Hames2019-10-151-2/+2
| | | | | | | | | | | | | | InProcessMemoryManager used to make separate memory allocation calls for each permission level (RW, RX, RO), which could lead to target-out-of-range errors if data and code were placed too far apart (this was the source of failures in the JITLink/AArch64 testcase when it was first landed). This patch updates InProcessMemoryManager to allocate a single slab which is subdivided between text and data. This should guarantee that accesses remain in-range provided that individual object files do not exceed 1Mb in size. This patch also re-enables the JITLink/AArch64 testcase. llvm-svn: 374948
* [JITLink] Disable the MachO/AArch64 testcase while investigating bot failures.Lang Hames2019-10-111-2/+2
| | | | | | | | The windows bots are failing due to a memory layout error. Temporarily disabling while I investigate whether this can be worked around, or whether the test should be disabled on Windows. llvm-svn: 374500
* [JITLink] Add an initial implementation of JITLink for MachO/AArch64.Lang Hames2019-10-102-0/+341
| | | | | | | | | This implementation has support for all relocation types except TLV. Compact unwind sections are not yet supported, so exceptions/unwinding will not work. llvm-svn: 374476
* [JITLink] Move MachO/x86 got test further down in the data section.Lang Hames2019-10-101-12/+12
| | | | | | 'named_data' should be the first symbol in the data section. llvm-svn: 374475
* [JITLink] Switch from an atom-based model to a "blocks and symbols" model.Lang Hames2019-10-041-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | In the Atom model the symbols, content and relocations of a relocatable object file are represented as a graph of atoms, where each Atom represents a contiguous block of content with a single name (or no name at all if the content is anonymous), and where edges between Atoms represent relocations. If more than one symbol is associated with a contiguous block of content then the content is broken into multiple atoms and layout constraints (represented by edges) are introduced to ensure that the content remains effectively contiguous. These layout constraints must be kept in mind when examining the content associated with a symbol (it may be spread over multiple atoms) or when applying certain relocation types (e.g. MachO subtractors). This patch replaces the Atom model in JITLink with a blocks-and-symbols model. The blocks-and-symbols model represents relocatable object files as bipartite graphs, with one set of nodes representing contiguous content (Blocks) and another representing named or anonymous locations (Symbols) within a Block. Relocations are represented as edges from Blocks to Symbols. This scheme removes layout constraints (simplifying handling of MachO alt-entry symbols, and hopefully ELF sections at some point in the future) and simplifies some relocation logic. llvm-svn: 373689
* [JITLink] Don't under-align zero-fill sections.Lang Hames2019-08-271-0/+14
| | | | | | | If content sections have lower alignment than zero-fill sections then bump the overall segment alignment to avoid under-aligning the zero-fill sections. llvm-svn: 370072
* [ORC] Refactor definition-generation, add a generator for static libraries.Lang Hames2019-08-131-0/+11
| | | | | | | | | | | | | | | | | This patch replaces the JITDylib::DefinitionGenerator typedef with a class of the same name, and adds support for attaching a sequence of DefinitionGeneration objects to a JITDylib. This patch also adds a new definition generator, StaticLibraryDefinitionGenerator, that can be used to add symbols fom a static library to a JITDylib. An object from the static library will be added (via a supplied ObjectLayer reference) whenever a symbol from that object is referenced. To enable testing, lli is updated to add support for the --extra-archive option when running in -jit-kind=orc-lazy mode. llvm-svn: 368707
* [JITLink] Fix an overly-wide read in the MachO/x86-64 test case.Lang Hames2019-08-031-1/+1
| | | | | | This should fix the build failures on some of the 32-bit bots. llvm-svn: 367767
* [JITLink] Add support for MachO/x86-64 UNSIGNED relocs with length=2.Lang Hames2019-08-031-10/+19
| | | | | | | | | MachO/x86-64 UNSIGNED relocs are almost always 64-bit (length=3), but UNSIGNED relocs of length=2 are allowed if the target resides in the low 32-bits. This patch adds support for such relocations in JITLink (previously they would have triggered an unsupported relocation error). llvm-svn: 367764
* Re-apply r364600 with fixes.Lang Hames2019-06-281-0/+12
| | | | | Fix: MachO/X86_64_RELOC_GOT is a 32-bit reloc, so only compare 32 bits. llvm-svn: 364672
* Revert "[JITLink][MachO/x86-64] Add a testcase for X86_64_RELOC_GOT."Lang Hames2019-06-271-12/+0
| | | | | | Reverts commit r364600 while I investigate bot failures. llvm-svn: 364606
* [JITLink][MachO/x86-64] Add a testcase for X86_64_RELOC_GOT.Lang Hames2019-06-271-0/+12
| | | | | | This is the data-section counterpart to X86_64_RELOC_GOTPCREL. llvm-svn: 364598
* [lit] Delete empty lines at the end of lit.local.cfg NFCFangrui Song2019-06-177-7/+0
| | | | llvm-svn: 363538
* [ExecutionEngine] Add UnaryOperator visitor to the interpreterCameron McInally2019-06-101-0/+2
| | | | | | | | This is to support the unary FNeg instruction. Differential Revision: https://reviews.llvm.org/D62881 llvm-svn: 362941
* [RuntimeDyld] Apply padding and alignment bumps to all sections with stubs, andLang Hames2019-05-301-2/+3
| | | | | | | | | | | | | increase the MachO/x86-64 stub alignment to 8. Stub alignment should be guaranteed for any section containing RuntimeDyld stubs/GOT-entries. To do this we should pad and align all sections containing stubs, not just code sections. This commit also bumps the MachO/x86-64 stub alignment to 8, so that GOT entries will be aligned. llvm-svn: 362139
* Fix 2-field llvm.global_ctors `REQUIRES: asserts` tests after rL360742Fangrui Song2019-05-151-2/+2
| | | | llvm-svn: 360743
* Replace lit feature keyword 'not_COFF' with 'uses_COFF'.Paul Robinson2019-05-142-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D61791 llvm-svn: 360680
* [JITLink][MachO] Honor the no-dead-strip flag on nlist entries.Lang Hames2019-05-131-0/+9
| | | | llvm-svn: 360618
* [JITLink] Track section alignment and make sure it is respected during layout.Lang Hames2019-05-131-0/+20
| | | | | | | Previously we had only honored alignments on individual atoms, but tools/runtimes may assume that the section alignment is respected too. llvm-svn: 360555
* [JITLink] Add a test for zero-filled content.Lang Hames2019-05-121-0/+5
| | | | | | | | Also updates RuntimeDyldChecker and llvm-rtdyld to support zero-fill tests by returning a content address of zero (but no error) for zero-fill atoms, and treating loads from zero as returning zero. llvm-svn: 360547
* [JITLink][MachO] Mark atoms in sections 'no-dead-strip' set live by default.Lang Hames2019-05-101-0/+9
| | | | | | | | If a MachO section has the no-dead-strip attribute set then its atoms should be preserved, regardless of whether they're public or referenced elsewhere in the object. llvm-svn: 360477
* [JITLink] Fixed a signedness bug when processing X86_64_RELOC_SUBTRACTOR.Lang Hames2019-05-091-8/+8
| | | | | | | | Subtractor relocation addends are signed, so we need to read them via signed int pointers. Accidentally treating 32-bit addends as unsigned leads to out-of-range errors when we try to add very large (>INT32_MAX) bogus addends. llvm-svn: 360392
* Reapply r360194 "[JITLink] Add support for MachO .alt_entry atoms." with fixes.Lang Hames2019-05-071-1/+63
| | | | | | | | | This patch modifies MachOAtomGraphBuilder to use setLayoutNext rather than addEdge, and fixes a bug in the section layout algorithm that could result in atoms appearing more than once in the section ordering (which resulted in those atoms being assigned invalid addresses during layout). llvm-svn: 360205
* Revert r360194 "[JITLink] Add support for MachO .alt_entry atoms."Lang Hames2019-05-071-63/+1
| | | | | | The testcase is asserting on some bots - reverting while I investigate. llvm-svn: 360200
* [JITLink] Add support for MachO .alt_entry atoms.Lang Hames2019-05-071-1/+63
| | | | | | | | | | | | | | | | The MachO .alt_entry directive is applied to a symbol to indicate that it is locked (in terms of address layout and liveness) to its predecessor atom. I.e. it is an alternate entry point, at a fixed offset, for the previous atom. This patch updates MachOAtomGraphBuilder to check for the .alt_entry flag on symbols and add a corresponding LayoutNext edge to the atom-graph. It also updates MachOAtomGraphBuilder_x86_64 to generalize handling of the X86_64_RELOC_SUBTRACTOR relocation: previously either the minuend or subtrahend of the subtraction had to be the same as the atom being fixed up, now it is only necessary for the minuend or subtrahend to be locked (via any chain of alt_entry directives) to the atom being fixed up. llvm-svn: 360194
* [JITLink] Fix some copy/paste related typos in a test case.Lang Hames2019-05-071-20/+21
| | | | | | | Several X86_64_RELOC_SUBTRACTOR tests for subtrahend handling were incorrectly labeled as tests for kinds of minuend handling. llvm-svn: 360160
* [llvm-readobj] Change -long-option to --long-option in tests. NFCFangrui Song2019-05-011-1/+1
| | | | | | | | | | We use both -long-option and --long-option in tests. Switch to --long-option for consistency. In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf. While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf). llvm-svn: 359649
* [ORC] Add a 'plugin' interface to ObjectLinkingLayer for events/configuration.Lang Hames2019-04-261-6/+1
| | | | | | | | | | | | | ObjectLinkingLayer::Plugin provides event notifications when objects are loaded, emitted, and removed. It also provides a modifyPassConfig callback that allows plugins to modify the JITLink pass configuration. This patch moves eh-frame registration into its own plugin, and teaches llvm-jitlink to only add that plugin when performing execution runs on non-Windows platforms. This should allow us to re-enable the test case that was removed in r359198. llvm-svn: 359357
* Revert "[JITLink] Make the JITLink MachO/x86-64 eh-frame test work on Windows."Lang Hames2019-04-251-1/+6
| | | | | | This reverts r359169, as it broke one of the windows bots. llvm-svn: 359198
* [JITLink] Make the JITLink MachO/x86-64 eh-frame test work on Windows.Lang Hames2019-04-251-6/+1
| | | | | | | This should fix the MachO/x86-64 eh-frame regression test by ensuring that the symbols __ZTIi and ___gxx_personality_v0 are defined on all platforms. llvm-svn: 359169
* Mark new jitlink test XFAIL for windowsReid Kleckner2019-04-241-1/+6
| | | | llvm-svn: 359151
* [JITLink] Refer to FDE's CIE (not the most recent CIE) when parsing eh-frame.Lang Hames2019-04-243-15/+20
| | | | | | | | | | | | | | | Frame Descriptor Entries (FDEs) have a pointer back to a Common Information Entry (CIE) that describes how the rest FDE should be parsed. JITLink had been assuming that FDEs always referred to the most recent CIE encountered, but the spec allows them to point back to any previously encountered CIE. This patch fixes JITLink to look up the correct CIE for the FDE. The testcase is a MachO binary with an FDE that refers to a CIE that is not the one immediately proceeding it (the layout can be viewed wit 'dwarfdump --eh-frame <testcase>'. This test case had to be a binary as llvm-mc now sorts FDEs (as of r356216) to ensure FDEs *do* point to the most recent CIE. llvm-svn: 359105
* [JITLink] Disable MachO/x86-64 regression test if the X86 target is not built.Lang Hames2019-04-202-0/+3
| | | | llvm-svn: 358830
* Initial implementation of JITLink - A replacement for RuntimeDyld.Lang Hames2019-04-201-0/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-128-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [yaml2obj]Allow explicit symbol indexes in relocations and emit error for ↵James Henderson2019-03-121-1/+0
| | | | | | | | | | | | | | | | | | | | | bad names Prior to this change, the "Symbol" field of a relocation would always be assumed to be a symbol name, and if no such symbol existed, the relocation would reference index 0. This confused me when I tried to use a literal symbol index in the field: since "0x1" was not a known symbol name, the symbol index was set as 0. This change falls back to treating unknown symbol names as integers, and emits an error if the name is not found and the string is not an integer. Note that the Symbol field is optional, so if a relocation doesn't reference a symbol, it shouldn't be specified. The new error required a number of test updates. Reviewed by: grimar, ruiu Differential Revision: https://reviews.llvm.org/D58510 llvm-svn: 355938
* Implement IMAGE_REL_AMD64_SECREL for RuntimeDyldCOFFX86_64Nathan Lanza2018-12-121-0/+14
| | | | | | | | 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][Interpreter] Fix out-of-bounds array access.Lang Hames2018-11-201-0/+10
| | | | | | | | | | If args is empty then accesing element 0 is illegal. https://reviews.llvm.org/D53556 Patch by Eugene Sharygin. Thanks Eugene! llvm-svn: 347281
* [ORC] Re-apply r345077 with fixes to remove ambiguity in lookup calls.Lang Hames2018-10-232-0/+23
| | | | llvm-svn: 345098
* Revert r345077 "[ORC] Change how non-exported symbols are matched during ↵Reid Kleckner2018-10-232-23/+0
| | | | | | | | | | | | | | | 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-232-0/+23
| | | | | | | | | | | | | | | | | 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-3/+3
| | | | | | | | | | | | | | | | | | 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] Add some more basic sanity tests for the LLJIT.Lang Hames2018-10-203-0/+25
| | | | | | | | | | | | minimal.ll contains a main function that returns zero, and single-function-call.ll contains a main function that calls a foo function that returns zero. These minimal tests can help to rule out some trivial JIT bugs when other tests fail. This commit also renames hello.ll to global-ctors-and-dtors.ll, which better reflects what it is actually testing. llvm-svn: 344863
OpenPOWER on IntegriCloud