The corresponding function definition was removed by:
commit 7a9c62baa66ae262755db0d3221ce095d48681d5
Author: Reid Spencer <rspencer@reidspencer.com>
Date: Fri Jan 12 07:05:14 2007 +0000
When llvm Interpreter is used to execute bitcode, it shall be able to handle TargetExtType.
Reviewed By: jcranmer-intel
Differential Revision: https://reviews.llvm.org/D148283
This patch introduces a skeleton JITLink ppc64 support header and ELF/ppc64
backend. No relocations are supported in this initial version, but given a
program requiring no relocations (e.g. one that just returns a constant value
from main) the new backend is able to construct a LinkGraph from a ppc64 ELF
relocatable object, and the llvm-jitlink tool is able to execute it.
This commit should also serve as a good example of how to introduce a JITLink
backend for a new architecture.
Reviewed By: sgraenitz, v.g.vassilev, vchuravy, nemanjai, jain98, MaskRay
Differential Revision: https://reviews.llvm.org/D148192
For linker relaxation (D149526), a new edge kind (`CallRelaxable`) was
introduced. However, this new kind was not taken into account by
`PerGraphGOTAndPLTStubsBuilder_ELF_riscv`. This patch fixes this.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D150957
These were previously re-enabled in d771f54107c, but had to be disabled again
in 2060a72b4d7 due to test failures.
This is a next step to landing https://reviews.llvm.org/D148192, which adds
a skeleton JITLink backend for PowerPC.
The fixes for those failures were (1) to explicitly specify IsLittleEndian =
true for the MachO YAML testcases, (2) disable some example tests for examples
that aren't supported on PowerPC yet, and (3) fixing the endianness of a
relocation read/write (for ELF R_AARCH64_TSTBR14) in RuntimeDyldELF.
This relocation is used for the 14-bit immediate in test and branch
instructions.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D150778
This patch is essentially an adaption of LLD's algorithm to JITLink.
Currently, only relaxing R_RISCV_CALL(_PLT) and R_RISCV_ALIGN is
implemented, other relocations can follow later.
From a high level, the algorithm works as follows. In the first phase
(relaxBlock), we iteratively try to relax all instructions that have a
R_RISCV_RELAX relocation:
- If, based on the current symbol values, an instruction sequence can be
relaxed (i.e., replaced by a shorter instruction), we record how many
bytes would be removed, the new instruction (Writes), and the new
relocation type (EdgeKinds).
- We keep track of the total number of bytes that got removed up to each
relocation in the RelocDeltas array. This is the cumulative sum of the
number of bytes removed for each relocation.
- Symbol values and sizes are updated based on the number of removed
bytes.
- If for any relocation, the current RelocDeltas value doesn't match the
one from the previous iteration, something changed and we need to run
another iteration as some symbols might now have different values.
In the second phase (finalizeBlockRelax), all code is moved based on
RelocDeltas, the relaxed instructions are rewritten using Writes, and
R_RISCV_ALIGN is handled (moving instructions to ensure alignment and
inserting the correct NOP-sequence if needed). Finally, edge kinds and
offsets are updated and all R_RISCV_RELAX and R_RISCV_ALIGN edges are
removed (they are not needed anymore for the fixup linking stage).
Linker relaxation is implemented as a pass and added to PreFixupPasses
in the default configuration on RISC-V.
Since linker relaxation removes instructions, the memory for blocks
should ideally be reallocated. However, I believe this is currently not
possible in JITLink. Therefore, relaxation directly modifies the memory
of blocks, reducing the number of instructions but not the size of
blocks. I'm not very familiar with JITLink's memory allocators so I
might be overlooking something here, though.
Note on testing: some of the tests rely on the debug output of
llvm-jitlink. The main reason for this is the verification of symbol
sizes (which may change due to relaxation). I don't believe this can be
done using jitlink-check checks alone.
Note that there is a slightly unrelated change that makes
Symbol::setOffset public to be able to update symbol offsets during
relaxation.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D149526
This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some
targets might use this information while linking.
One example, and the reason this patch was written, is linker relaxation
on RISC-V: different relaxations are possible depending on if the C
extension is enabled.
Note that the features are stored as `std::vector<std::string>` to prevent a
public dependency on MC. There is still a private dependency to be able to
convert SubtargetFeatures to a vector.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D149522
Some relocations (e.g., R_RISCV_ALIGN) don't have a target symbol and
use a null symbol as a placeholder. These symbols were not processed
before making it impossible to create edges for them.
This patch tries to detect these null symbols and create absolute
symbols for them. Note that technically, these null symbols are UND in
the ELF file, not ABS, so it might make more consistent to create a new
symbol type for this (local undefined or so). However, since these
symbols are only used as placeholders (i.e., their values are never
used), I don't think it's worth the effort of doing this.
Also note that in the binaries that I have inspected, this null symbol
always has index 0. Could it make sense to add that to the test to avoid
accidentally adding unnecessary symbols? The reason I didn't do this
yet, is that I couldn't find any references in the specs that actually
guarantee this.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D149541
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
This relocation is used for the 19-bit immediate in conditional branch
and compare and branch instructions.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D149138
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 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 allows the subsequent code to access the E_IDENT fields, which will be
used in the upcoming JITLink ppc64 backend (https://reviews.llvm.org/D148192).
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.
Adds support for the R_X86_64_GOTPC32 relocation, which is a 32-bit delta to
the global offset table.
Since the delta to the GOT doesn't actually require any GOT entries to exist
this commit adds an extra fallback path to the getOrCreateGOTSymbol function:
If the symbol is in the extenal symbols list but no entry exists then the
symbol is turned into an absolute symbol pointing to an arbitrary address in
the current graph's allocation (accessing this address via the symbol would be
illegal, but any access should have triggered creation of a GOT entry which
would prevent this fallback path from being taken in the first place).
This commit also updates the llvm-jitlink tool to scrape the addresses of the
absolute symbols in the graph so that the testcase can see the now-absolute
_GLOBAL_OFFSET_TABLE_ symbol.
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 the default link configuration, PLT stubs are created automatically
for R_RISCV_CALL_PLT relocations and the relocation itself is
transformed to R_RISCV_CALL (PerGraphGOTAndPLTStubsBuilder_ELF_riscv).
Only the latter is later handled when applying fixups and the former is
simply ignored.
This patch proposes to handle R_RISCV_CALL_PLT anyway when applying
fixups to support custom configurations that do not need automatic PLT
creation. An example of this is BOLT where PLT entries from the input
binary are reused (D147544).
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D148238
This comment was probably mangled when the generic ELFLinkGraphBuilder was
written from the original x86-64 specific version. Regardless of its origins,
it doesn't make any sense now.
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
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.
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.
The various ADD/SUB relocations work by reading the current value the
relocation points to, transforming it, and then writing it back to
memory. While the current implementation writes the value back to
working memory, it reads the current value from the execution address of
the relocation. This causes at least wrong results, but often crashes,
when the addresses of working memory are not equal to execution
addresses. This patch fixes this by reading the current value from
working memory.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D147693
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
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).
We create LinkGraph sections with NoAlloc lifetime now since f05ac803ffe76c7f4299a4e1288cc6bb8b098410
This means we do process debug info sections now with all their relocations. That's ok for the moment.
All non-executable sections used to be mapped as RW- causing read-only
sections such as .rodata to be writable.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D147442
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
