This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
In ELF, symbols of type STT_GNU_IFUNC need to be resolved by calling the
function at the symbol's address. This is implemented by adding special
stubs for all symbols of that type.
Differential Revision: https://reviews.llvm.org/D105465
Updates the aarch64 pointer jump stub sequence to:
ADRP x16, <ptr>@page21
LDR x16, [x16, <ptr>@pageoff12]
BR x16
from:
LDR x16, <ptr>@ldrimm19
BR x16
The old sequence can only reference pointers within +/-1Mb, which may not be
enough for large object files. The new sequence can reach pointers within
+/-4Gb. (A future pre-fixup-pass could apply range-based optimizations to
turn this into an ldr-br-nop sequence.)
Also adds createPointerJumpStubBlock and createAnonymousPointerJumpStub
utilities along the same lines as their x86-64 counterparts.
The PLTTableManager is updated to use the new utility functions.
This brings the aarch64 edges into alignment with the naming scheme for the
x86-64 edges.
Edge behavior is mostly unchanged, but some irrelevant assertions and errors
have been removed.
This commit adds support for 32 bit absolute and pc relative relocations in
ELF/i386 objects, along with simple regression tests.
Reviewed By: sgraenitz, lhames
Differential Revision: https://reviews.llvm.org/D135523
Pointer64Anon was lifted out of the MachO backend and into aarch64.h when that
header was created, but Pointer64Anon is really a MachO-specific "normalized"
relocation value, rather than a generic Edge::Kind. Any uses can be safely
replaced with Pointer64.
(Side note: the role of MachOPointer64Anon is to aid MachO relocation parsing:
For MachOPointer64, the target symbol is specified by the r_symbolnum field in
the relocation. For MachOPointer64Anon the address of the anonymous target is
read from the fixup location.)
ObjectLinkingLayer attempts to claim responsibility for weak definitions that
are present in LinkGraphs, but not present in the corresponding
MaterializationResponsibility object. Where such a claim is successful, the
symbol should be marked as live to prevent it from being dead stripped.
(For the curious: Such "late-breaking" definitions are introduced somewhere in
the materialization pipeline after the initial responsibility set is calculated.
The usual source is the complier or assembler. Examples of common late-breaking
definitions include personality pointers, e.g. "DW.ref.__gxx_personality_v0",
and named constant pool entries, e.g. __realXX..XX.)
The failure to mark these symbols live caused few problems in practice because
late-breaking definitions are usually anchored by existing live definitions
within the graph (e.g. DW.ref.__gxx_personality_v0 is transitively referenced by
functions via eh-frame records), and so they usually survived dead-stripping
anyway. This accidental persistence isn't a principled solution though, and it
fails altogether if a late-breaking definition is not otherwise referenced by
the graph, with the result that the now-claimed symbol is stripped triggering a
"Failed to materialize symbols" error in ORC. Marking such symbols live is the
correct solution.
No testcase, as it's difficult to construct a situation where a late-breaking
definition is inserted without being referenced outside the context of new
backend bringup or plugin-specific shenanigans.
See discussion in https://reviews.llvm.org/D133452 and
https://reviews.llvm.org/D136877.
It is confusing to see "Unrecognized edge kind" in debugging output
for supported relocations; this was probably an oversight in commit
89f546f6ba which added the support.
Differential Revision: https://reviews.llvm.org/D136985
We don't need to provide a load-address for non-alloc sections. Skipping them
allows us to avoid some complications, like handling duplicate .group sections.
Adds a generic utility for creating anonymous aarch64 pointer blocks
(automatically adding an edge to initialize the pointer if given an
initial target).
Updates the aarch64 GOTTableManager to use the utility when building
GOT entries.
Similar to the EPCEHFrameRegistrar change in c977251ef6, this allows clients
who have sourced a dylib handle via a side-channel to search that dylib to
find the registration functions.
This patch defaults to the existing behavior in the case where the client does
not specify a handle to use.
SelfExecutorProcessControl no longer requires that handles passed to
lookupSymbols be ones that were previously returned from loadDylib. This brings
SelfExecutorPRocessControl into alignment with SimpleRemoteEPC, which was
updated in 6613f4aff8.
Previously, EPCEHFrameRegistrar always used the
ExecutorProcessControl::loadDylib(nullptr) method to obtain a handle for the
process, but this doesn't work if the registration functions aren't visible in
a standard search of the process (e.g. if the JIT is in a plugin that is loaded
with RTLD_LOCAL).
This patch retains the old behavior by default, but allows clients to supply
their own handle for the library containing the registration functions if they
need to (e.g. to work around limitations like RDLD_LOCAL above, which aren't
expressible within the existing loadDylib / DynamicLibrary APIs).
Updates tpctypes::DylibHandle to be an ExecutorAddr (rather than a uint64_t),
and SimpleExecutorDylibManager to hold and return raw OS handle values (as
ExecutorAddrs) rather than index values into a map of DynamicLibrary instances.
This will allow clients to use EPCGenericDylibManager in contexts where the
existing DynamicLibrary interface is too limited to be used. (e.g. to look up
JIT symbols in a dylib that was loaded with RTLD_LOCAL).
Since aedeb8d557, which switched to EPC-based eh-frame registrationin LLJIT,
the eh-frame registration functions need to be forcibly linked into the target
process.
Failure to link the eh-frame registration functions triggered a test failure in
https://green.lab.llvm.org/green/job/clang-stage1-RA/31497, which was fixed by
forcibly linking the registration functions into that test case in saf2b2214b4
(rdar://101083784), however it has also caused some tests (e.g. the C API unit
tests) that depend on successful construction of an LLJIT instance to be
skipped.
Moving the forcible registration into LLJIT.cpp fixes the general issue.
Now that ExecutionSession objects alway have ExecutorProcessControl (EPC)
objects attached we can use EPCEHFrameRegistrar by default, rather than
InProcessEHFrameRegistrar. This allows LLJIT to work out-of-the-box with remote
EPCs on platforms that use JITLink, without requiring a custom
ObjectLinkingLayerCreator to override the eh-frame registrar.
This is a counterpart to ffe2dda29f, and does for scope what that commit did
for linkage.
Making the scope of external definitions visible to JITLink plugins will
allow us to distinguish hidden weak defs (which do not need to be tracked by
default) from default-scoped weak defs (which need to be updated to point at
a single chosen definition at runtime).
Previously we stripped Weak flags from JITDylib symbol table entries once they
were resolved (there was no particularly good reason for this). Now we want to
retain them and query them when setting the Linkage on external symbols in
LinkGraphs during symbol resolution (this was the motivation for 75404e9ef8).
Making weak linkage of external definitions discoverable in the LinkGraph will
in turn allow future plugins to implement correct handling for them (by
recording locations that depend on exported weak definitions and pointing all
of these at one chosen definition at runtime).
