| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This re-applies 4b17c81d5a5, "[jitlink/rtdydl][checker] Add TargetFlag
dependent disassembler switching support", which was reverted in
4871a9ca546 due to bot failures.
The patch has been updated to add missing plumbing for Subtarget Features and
a CPU string, which should fix the failing tests.
https://reviews.llvm.org/D158280
|
|
switching support"
This reverts commit 4b17c81d5a5d3e0f514026c2b7f9b623d901cc04.
Caused buildbot failures:
https://lab.llvm.org/buildbot/#/builders/230/builds/18341
https://lab.llvm.org/buildbot/#/builders/109/builds/73169
https://lab.llvm.org/buildbot/#/builders/67/builds/12597
|
|
support
Some targets such as AArch32 make use of TargetFlags to indicate ISA mode. Depending
on the TargetFlag, MCDisassembler and similar target specific objects should be
reinitialized with the correct Target Triple. Backends with similar needs can
easily extend this implementation for their usecase.
The drivers llvm-rtdyld and llvm-jitlink have their SymbolInfo's extended to take
TargetFlag into account. RuntimeDyldChecker can now create necessary TargetInfo
to reinitialize MCDisassembler and MCInstPrinter. The required triple is obtained
from the new getTripleFromTargetFlag function by checking the TargetFlag.
In addition, breaking changes for RuntimeDyld COFF Thumb tests are fixed by making
the backend emit a TargetFlag.
Reviewed By: lhames, sgraenitz
Differential Revision: https://reviews.llvm.org/D158280
|
|
This reverts commit 75c487602a8af130ec0aedf398e318cb57063f2d while I
investigate some build failures, e.g.
https://lab.llvm.org/buildbot/#/builders/217/builds/27769
|
|
Adds a utility for creating MachO objects. In this patch we use this utility to
construct "debug objects" for the debugger support plugin; however, this utility
should be reusable for other purposes, e.g. constructing object files for
registration with the ObjC runtime.
The debug objects in this patch are created by the MachO JIT debugging-support
plugin. The debug objects hold the debug info for object files loaded under the
JIT, and are registered with the debugger via the GDB-JIT interface. Previously
the plugin created these objects manually using direct writes to a buffer, but
this was difficult to read and modify and had become an impediment to improving
debugger support (e.g. getting source debugging working in the presence of
dead-stripping). Using the MachOBuilder utility should make the debugger
support plugin easier to maintain and improve.
This initial change to MachO JIT'd code debugging aims for feature parity with
the existing plugin (though the debug objects produced are slightly different).
Improvements to JIT'd code debugging will be tackled in follow-up patches.
|
|
Should fix error in https://lab.llvm.org/buildbot/#/builders/84/builds/41540.
|
|
By using bootstrap symbols to communicate these addresseses, rather than dlsym
lookups, we no longer need them to be exported from the main executable. On ELF,
where symbols aren't exported from the main executable by default, this
eliminates a common source of missing symbol errors and allows for smaller
executables (if exports from the main executable aren't otherwise needed and
can be removed).
|
|
For many interesting process-symbols setups we need access to the LLJIT instance
(e.g. to mangle symbols, or inspect the process triple). This patch updates the
ProcessSymbolsJITDylibSetupFunction to take an LLJIT reference and return the
process symbols JITDylib, which the callback must now create.
|
|
Reviewed By: sgraenitz
Differential Revision: https://reviews.llvm.org/D157226
|
|
Creating stubs in JITLink require creating architecture-specific edges. In order to allow user to create stubs in cross-architecture manner, this patch exposes these stub creations functions by returning "stub creators" for given triple.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D155557
|
|
Since jitlink for ppc64le is ready for general use, test cases in compiler-rt for ELFNixPlatform support can be enabled.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D156399
|
|
Access to individual DefinitionGenerators is serialized in order to make
generators easier to implement: serializing access means that tryToGenerate
methods don't have to handle concurrent, potentially overlapping, requests.
Prior to this patch serialization was achieved by having each lookup acquire a
lock on each generator, however this causes the lookup thread to block if the
generator is in use. In the common case where many objects reference some
common library symbol that is provided by a generator this may cause many
threads to block concurrently preventing progress on other work.
This patch changes the model so that lookups are automatically suspended if
they need to use a generator that is already in use, and then automatically
resumed once the generator is free. This is achieved by reusing the lookup
suspension machinery that was introduced in 069919c9ba3 for optionally
asynchronous generators.
|
|
|
|
The ExecutionSession::removeJITDylibs operation will remove all JITDylibs in
the given list (i.e. first clear them, then remove them from the session).
ExecutionSession::endSession is updated to remove JITDylibs rather than just
clearing them. This prevents new code from being added to any JITDylib once
endSession has been called.
|
|
ELF object files can contain `.ctors` and `.dtors` sections that also
participate as initializers.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D154802
|
|
It currently depends on the StringMap iteration order, which is not
guaranteed to be deterministic. Use MapVector to stabilize the order.
|
|
An in-flight materialization may try to claim responsibility for new symbols
(via MaterializationResponsibility::defineMaterializing) after the tracker that
is associated with the materialization is removed, leaving the tracker defunct.
Failure to error out early here could leave the JITDylib in an invalid state,
with defineMaterializing associating new symbols with the already-defunct
tracker. Erroring out early prevents this.
|
|
|
|
|
|
GCC warns when strncpy doesn't copy the null terminator. See discussion at
https://reviews.llvm.org/rG9d701c8a8d65.
|
|
Thanks to Simon Pilgrim for letting me know about these in
https://reviews.llvm.org/rG9d701c8a8d65.
|
|
In OrcAArch64::writeIndirectStubsBlock, masks the high bits of the immediate
operand to the stub's ldr instruction so that negative offsets to the stub
pointer do not overflow.
No testcase -- this fixes most of the OrcLazy testcases for AArch64 (at least on
Darwin), but we still need to fix the exception-handling test before we can turn
them on.
|
|
This patch removes:
cloneModuleFlagsMetadata
moveFunctionBody
moveGlobalVariableInitializer
Their last uses were removed by:
commit 6154c4115cd4b78d0171892aac21e340e72e32bd
Author: Lang Hames <lhames@gmail.com>
Date: Mon Sep 7 21:21:28 2020 -0700
Differential Revision: https://reviews.llvm.org/D152668
|
|
{starts,ends}_with_insensitive (NFC)
This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view. I'm planning to deprecate
StringRef::{starts,ends}with_insensitive once the migration is
complete across the code base.
Differential Revision: https://reviews.llvm.org/D150426
|
|
The __objc_imageinfo section may be deleted (leaving dangling references to any
symbols that it contains), and shouldn't have any dependencies anyway. This
patch verifies that the section has no dependencies and then skips the section.
rdar://108469243
|
|
Currently clangDriver passes -femulated-tls and -fno-emulated-tls to cc1.
cc1 forwards the option to LLVMCodeGen and ExplicitEmulatedTLS is used
to decide the value. Simplify this by moving the Clang decision to
clangDriver and moving the LLVM decision to InitTargetOptionsFromCodeGenFlags.
|
|
This reapplies 85c649bc02a, which was reverted in 35767e43d62 due to failures
with some example programs. The fix was to add export_executable_symbols to the
example programs.
|
|
This reverts commit 85c649bc02a6605f541b09b33a200a78275ed90f.
Has been causing test failures in OrcV2Examples for the past few
days.
|
|
|
|
This reverts commit 76e1521b0acff739c0425d0fcbb9360fc17f1af8.
|
|
This patch ports PerfJITEventListener to a JITLink plugin, but adds unwind record support and drops debuginfo support temporarily. Debuginfo can be enabled in the future by providing a way to obtain a DWARFContext from a LinkGraph.
See D146060 for an experimental implementation that adds debuginfo parsing.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D146169
|
|
This patch switches LLJIT's default JIT linker for ELF/x86-64 from RuntimeDyld
to JITLink.
Most clients should not be affected, but if you were explicitly accessing the
old RTDyldObjectLinkingLayer (e.g. to install JITEventListeners) you will need
to either force use of RuntimeDyld (following the example in
llvm/examples/OrcV2Examples/LLJITWithCustomObjectLinkingLayer), or switch to
using JITLink plugins instead.
|
|
Clients can now call LLJITBuilder::setEnableDebuggerSupport to enable
registration of debug info via the GDB-JIT registration protocol for JIT'd
code.
Calling LLJITBuilder::setEnableDebuggerSupport(true) will cause LLJITBuilder to
add either a DebugObjectManagerPlugin (if the object format on the triple is
ELF), or a GDBJITDebugInfoRegistrationPlugin (if the object format on the
triple is MachO). At present there is no support for debugging when using COFF.
This debugger registration support will only work when JITLink is used as the
underlying JIT linker.
This patch only addresses registration of JIT'd code by the JIT. To debug JIT'd
code you may also need to enable JIT'd code debugging in your debugger. E.g.
when debugging MachO JIT'd code under LLDB you will currently need to run
(lldb) set set plugin.jit-loader.gdb.enable on
to tell LLDB to listen for JIT'd code registration.
|
|
In f448d44663a we switched to calling _objc_map_images and _objc_load_images
for MachO language metadata registration. This patch fixes some bugs arising
from that change:
(1) __objc_imageinfo processing was moved to a post-allocation pass, but this
prevents us from discarding the redundant copies. This commit moves
processing back to a pre-prune pass and inserts a symbol for the uniqued
__objc_image section. Runtime objects use an edge pointing to this symbol
to access the address.
(2) We were assuming that _objc_map_images & _objc_load_images were available
in the Objective-C runtime on 10.15, but these functions didn't become
available until later. This commit bumps the macOS version requirement to
13.1 where the functions should be available.
(3) The ORC-RT trivial-swift-types-section.S test was missing an
__objc_unwindinfo section, which triggered an assert that should have
been an error. The assert has been turned into an error, and the testcase
has been updated to include an __objc_imageinfo.
rdar://107846455
|
|
Fixes error about missing reference to __atomic_fetch_add_8 when linking
LLVMOrcJit on ARMv6.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D147937
|
|
|
|
A map value was converted from a tuple to a struct during development, but I
missed a use in an assert.
|
|
This patch drops the individual registration calls to the ObjC and Swift
runtimes (for selectors, classes, etc.), and instead creates a Mach header and
load commands that can be passed to _objc_map_images and _objc_load_images to
trigger registration and execution of +load methods. This approach supports
categories (for which there is no current registration API), and more closely
follows dyld's ObjC & Swift registration path.
|
|
Clients can provide an ExecutionSession or an ExecutorProcessControl object to
LLJITBuilder, but should not provide both.
|
|
This reapplies 371cb1af61d, which was reverted in 0b2240eda01 due to bot
failures.
The clang-repl test failure is fixed by dropping the process symbols definition
generator that was manually attached to the main JITDylib, since LLJIT now
exposes process symbols by default. (The bug was triggered when JIT'd code used
the process atexit provided by the generator, rather than the JIT atexit which
has been moved into the platform JITDylib).
Any LLJIT clients that see crashes in static destructors should likewise remove
any process symbol generators attached to their main JITDylib.
|
|
This reverts commit 371cb1af61d668234a242b34c773c146cb9077e7, which broke some
unit tests (see e.g. https://lab.llvm.org/buildbot#builders/139/builds/38754).
|
|
This commit includes several related ergonomic improvements to LLJIT.
(1) Adds a default JITDylibSearchOrder to be appended to the initial link order
of JITDylibs created via LLJIT::createJITDylib (dropping any duplicate entries).
This was introduced to support automatic reflection of process symbols (see
(2) below), but has been made visible to clients as it's generically useful,
e.g. if clients have some extra set of libraries that they want to be visible
to JIT'd code by default.
The default JITDylibSearchOrder is only appended to the link order of JITDylibs
created via LLJIT::createJITDylib, and will not be apply to JITDylibs created by
directly calling the underlying ExecutionSession -- in that case clients can set
up the link order manually.
(2) Makes process symbols visible to JIT'd code by default via the new "Process"
JITDylib, which is added to the default link order.
LLJIT clients usually want symbols in the executor process to be accessible to
JIT'd code. Until now clients have been left to set this up themselves by adding
a DynamicLibrarySearchGenerator to the Main JITDylib. This patch adds a new
process symbols JITDylib that will be created by default (with an
EPCDynamicLibrarySearchGenerator attached) and added to the default link order,
making process symbols available to JIT'd code.
Clients who do not want process symbols to be visible to JIT'd code by default
can call setLinkProcessSymbolsByDefault(false) on their LLJITBuilder to disable
this:
LLJITBuilder()
...
.setLinkProcessSymbolsByDefault(false)
...
.create();
Clients can also call setProcessSymbolsJITDylibSetup to take over responsibility
for configuring the process symbols JITDylib (the callback that the client
supplies will be called on the bare process symbols JITDylib immediately after
it is created).
If setLinkProcessSymbolsByDefault(false) is called and no JITDylib setup
callback has been set then the process symbols JITDylib will not be created and
LLJIT::getProcessSymbolsJITDylib will return null.
(3) Adds an ExecutorNativePlatform utility that makes it easier to enable
native platform features.
Some object format features (e.g. native static initializers and thread locals)
require runtime support in the executing process. Support for these features in
ORC is implemented cooperatively between the ORC runtime and the LLVM Platform
subclasses (COFFPlatform, ELFNixPlatform, and MachOPlatform).
ExecutorNativePlatfrom simplifies the process of loading the ORC runtime and
creating the appropriate platform class for the executor process.
ExecutorNativePlatform takes a path to the ORC runtime (or a MemoryBuffer
containing the runtime) and other required runtimes for the executor platform
(e.g. MSVC on Windows) and then configures LLJIT with an appropriate platform
class based on the executor's target triple:
LLJITBuilder()
.setPlatformSetUp(ExecutorNativePlatform("/path/to/orc-runtime.a"));
(The ORC runtime is built as part of compiler-rt, and the exact name of the
archive is platform dependent).
The ORC runtime and platform symbols will be added to a new "Platform" JITDylib,
which will be added to the *front* of the default link order (so JIT'd code will
prefer symbol definitions in the platform/runtime to definitions in the executor
process).
ExecutorNativePlatform assumes that the Process JITDylib is available, as
the ORC runtime may depend on symbols provided by the executor process.
Differential Revision: https://reviews.llvm.org/D144276
|
|
This appends the given JITDylibSearchOrder to the JITDylib's existing one.
|
|
ORC's ELF platform support prefers the newer libunwind registration functions
(__unw_add_dynamic_eh_frame_section, __unw_remove_dynamic_eh_frame_section) when
they're available, and falls back to the older registration functions
(__register_frame, __deregister_frame) when they're not.
Until now the choice of registration functions has been made on the controller
side in ELFNixPlatform: The platform JITDylib was searched for the registration
functions and aliases set depending on which ones were found. This patch drops
that selection logic from ELFNixPlatform and instead uses weak imports of the
registration functions in elfnix_platform.cpp to identify which ones are
available and choose which ones to use.
This has a few small benefits:
(1) The registration functions don't need to be defined in the same JITDylib as
the ORC runtime -- it's sufficient for them to be defined in a JITDylib that the
ORC runtime's JITDylib links against.
(2) THe elfnix_platfrom code is more readable, as we don't have to dig into
ELFNixPlatform.cpp on the controller side to discover the definition of the
registration aliases.
(3) We may save a separate round-trip to look up the registration APIs (the
lookup will be folded into the ordinary external symbol lookup when linking the
runtime).
|
|
Configure the plugin to automatically call the debugger rendezvous breakpoint `__jit_debug_register_code()` for every translation unit (enabled) or never at all (disabled). Default API and behavior remain unchanged.
If AutoRegisterCode is turned off, it's the client's own responsibility to call the rendezvous breakpoint function at an appropriate time.
Depending on the complexity of the debugger's rendezvous breakpoint implementation, this can provide significant performance improvements in cases where many debug objects are added in sequence.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D147310
|
|
Apparently, the refactor in 8b1771bd9f304be39d4dcbdcccedb6d3bcd18200 broke the logic behind formatv here:
```
140736272011264 .rodata
140736272015360 .text
140736272011424 .eh_frame
```
|
|
SimpleRemoteEPC already included a "bootstrap symbols map" that could be used
to communicate the addresses of symbols needed for JIT bootstrap. The new
bootstrap map can be used to communicate arbitrary bootstrap values (encoded as
SPS buffers).
The bootstrap symbols map is kept as distinct becasue bootstrap symbols are
significant, and having a known value type for them allows for better debug
logging (we know how to render the values) and tooling (e.g. utils for adding
all bootstrap symbols to a JITDylib).
|
|
Commit 2666231d173 fixed a typo ("__objc_image_info" was corrected to
"__objc_imageinfo"), but this has exposed a bug where we were adding this
section to the list of platform sections to register with the ORC runtime.
The ORC runtime's MachO "object platform section" code doesn't recognize
this section (it's handled elsewhere) and errors out on it.
The solution is simply to remove __objc_imageinfo from the list of sections
to register in MachOPlatform::PlatformPlugin::registerObjectPlatformSections.
|
|
|
|
|
