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).
Introduces two new methods on Symbol: isWeaklyReferenced and
setWeaklyReferenced. These are now used to track/set whether an external symbol
is weakly referenced, rather than having the Symbol's linkage set to weak.
This change is a first step towards proper handling of weak defs used across
JITDylib boundaries: It frees up the Linkage field on external symbols so that
it can be used to represent the linkage of the definition that the symbol resolves
to. It is expected that Platform plugins will use this information to track
locations that need to be updated if the selected weak definition changes (e.g.
because JITDylibs were dlclosed and then dlopened again in a different order).
If we want to be able to close and then re-open a library then we need to reset
the data section states when the library is closed. This commit updates
MachOPlatform and the ORC runtime to track __data and __common sections, and
reset the state in MachOPlatformRuntimeState::dlcloseDeinitialize.
This is only a first step to full support -- there are other data sections that
we're not capturing, and we'll probably want a more efficient representation
for the sections (rather than passing their string name over IPC), but this is
a reasonable first step.
This commit also contains a fix to MapperJITLinkMemoryManager that prevents it
from calling OnDeallocated twice in the case of an error.
I'm planning to deprecate and eventually remove llvm::empty.
I thought about replacing llvm::empty(x) with std::empty(x), but it
turns out that all uses can be converted to x.empty(). That is, no
use requires the ability of std::empty to accept C arrays and
std::initializer_list.
Differential Revision: https://reviews.llvm.org/D133677
Removes public bootstrap method that is not really necessary and not consistent with other platform API.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D132780
Supports dynamic VC runtime. It implements atexits handling which is required to load msvcrt.lib successfully. (the object file containing atexit symbol somehow resolves to static vc runtim symbols) It also default to dynamic vc runtime which tends to be more robust.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D132525
This updates the ExecutorSharedMemoryMapperService::deinitialize and
InProcessMemoryMapper::deinitialize methods to deinitialize in reverse order,
bringing them into alignment with the behavior of
InProcessMemoryManager::deallocate and SimpleExecutorMemoryManager::deallocate.
Reverse deinitialization is required because later allocations can depend on
earlier ones.
This fixes failures in the ORC runtime test suite.
Kazu Hirata