Revert "[ORC] Enable JIT support for the compact-unwind frame info format..."

This reverts 4f0325873faccfbe171bae4babceb65975ca892e and follow-up patches
(see below) while I investigate some ongoing

Revert "[ORC] Enable JIT support for the compact-unwind frame info format..."

This reverts 4f0325873faccfbe171bae4babceb65975ca892e and follow-up patches
(see below) while I investigate some ongoing failures on the buildbots.

---

Revert "[clang-repl] Try to XFAIL testcase on arm32 without affecting arm64
darwin."

This reverts commit fd174f0ff3e793fe96a6663b1488ed159cfe042f.

Revert "[clang-repl] The simple-exception test now passes on arm64-darwin."

This reverts commit c9bc242e387f4a4a3dfcd86561f3ec0ca8a72d62.

Revert "[ORC] Destroy defunct MaterializationUnits outside the session lock."

This reverts commit a001cc0e6cdcfa672b8aff9ce6d14782bb96356a.

Revert "[ORC] Add explicit narrowing casts to fix build errors."

This reverts commit 26fc07d5d88760ad659599184fd10181287d2d9e.

Revert "[ORC] Enable JIT support for the compact-unwind frame info format on
Darwin."

This reverts commit 4f0325873faccfbe171bae4babceb65975ca892e.

show more ...

[ORC] Enable JIT support for the compact-unwind frame info format on Darwin.

For Darwin/arm64 (including Apple Silicon Macs) this will enable exception
handling and stack unwinding in JIT'd code.

D

[ORC] Enable JIT support for the compact-unwind frame info format on Darwin.

For Darwin/arm64 (including Apple Silicon Macs) this will enable exception
handling and stack unwinding in JIT'd code.

Darwin supports two unwind-info formats: DWARF eh-frames and compact-unwind. On
Darwin/x86-64 compilers usually produce both by default, and ORC supported
exceptions and unwinding via eh-frames (same as on Linux), discarding the
redundant compact-unwind info. On Darwin/arm64 compilers typically default to
producing compact-unwind only, with DWARF eh-frames as a fallback for functions
that can't be described in compact-unwind. Since ORC did not previously support
the compact-unwind format and eh-frames were not present ORC was unable to
handle exceptions or unwinding by default in Darwin/arm64 JIT'd code.

This patch enables support for the compact-unwind-info format, and contains
three major moving parts:

(1) The JITLink CompactUnwindManager class is responsible for transforming the
__compact_unwind records produced by the linker into the __unwind_info
tables that libunwind parses during unwinding. To enable this the
CompactUnwindManager class provides three JITLink passes: The
prepareForPrune pass that splits the __compact_unwind section into
single-record blocks, allowing unused records to be dead-stripped; the
processAndReserveUnwindInfo pass that reserves space for the final
__unwind_info section, and the writeUnwindInfo pass that writes the
__unwind_info section.

(2) The OrcTargetProcess UnwindInfoManager class maintains a table of
registered JIT'd __unwind_info and __eh_frame sections, and handles
requests from libunwind for unwind info sections (by registering a callback
with libunwind's __unw_add_find_dynamic_unwind_sections function).

(3) The Orc UnwindInfoRegistrationPlugin, which scans LinkGraphs for
__unwind_info and __eh_frame sections to register with the
UnwindInfoManager.

This commit adds the CompactUnwindManager passes to the default JITLink
pipelines for Darwin/arm64 and Darwin/x86-64, and UnwindInfoManager intances to
the SelfExecutorProcessControl class (when built for apple platforms) and the
llvm-jitlink-executor tool.

The LLJIT class will now create an UnwindInfoRegistrationPlugin when targeting
a process running on Darwin if it detects that an UnwindInfoManager is
available to handle the registrations.

The ORC runtime macho_platform class already supported libunwind callbacks, so
out-of-process execution and unwinding support will work when loading the ORC
runtime.

The llvm-jitlink tool will only support compact-unwind when the orc-runtime is
loaded, as the UnwindInfoRegistrationPlugin requires access to an IR compiler
to load a helper module and llvm-jitlink does not provide an IR compiler.

show more ...

[ExecutionEngine] Remove unused includes (NFC) (#116749)

Identified with misc-include-cleaner.

[ORC] Move EPC load-dylib and lookup operations into their own class.

This keeps common operations together, and should make it easier to write
re-usable dylib managers in the future (e.g. a DylibMa

[ORC] Move EPC load-dylib and lookup operations into their own class.

This keeps common operations together, and should make it easier to write
re-usable dylib managers in the future (e.g. a DylibManager that uses
the EPC's remote-execution APIs to implement load and lookup).

show more ...

Re-apply "[ORC] Unify task dispatch across ExecutionSession..." with more fixes.

This re-applies 6094b3b7db7, which was reverted in e7efd37c229 (and before that
in 1effa19de24) due to bot failures.

Re-apply "[ORC] Unify task dispatch across ExecutionSession..." with more fixes.

This re-applies 6094b3b7db7, which was reverted in e7efd37c229 (and before that
in 1effa19de24) due to bot failures.

The test failures were fixed by having SelfExecutorProcessControl use an
InPlaceTaskDispatcher by default, rather than a DynamicThreadPoolTaskDispatcher.
This shouldn't be necessary (and indicates a concurrency issue elsewhere), but
InPlaceTaskDispatcher is a less surprising default, and better matches the
existing behavior (compilation on current thread by default), so the change
seems reasonable. I've filed https://github.com/llvm/llvm-project/issues/89870
to investigate the concurrency issue as a follow-up.

Coding my way home: 6.25133S 127.94177W

show more ...

Revert "Re-apply [ORC] Unify task dispatch across ExecutionSession and..."

This reverts commit 1effa19de24 while I investigate the test failure at
https://lab.llvm.org/buildbot/#/builders/285/builds

Revert "Re-apply [ORC] Unify task dispatch across ExecutionSession and..."

This reverts commit 1effa19de24 while I investigate the test failure at
https://lab.llvm.org/buildbot/#/builders/285/builds/888.

show more ...

Re-apply "[ORC] Unify task dispatch across ExecutionSession and..." with fix.

This re-applies 6094b3b7db7, which was reverted in a28557aadd8 due to broken
bots. As far as I can tell all failures wer

Re-apply "[ORC] Unify task dispatch across ExecutionSession and..." with fix.

This re-applies 6094b3b7db7, which was reverted in a28557aadd8 due to broken
bots. As far as I can tell all failures were due to a missing #include <deque>,
which has been adedd in this commit.

show more ...

Revert "[ORC] Unify task dispatch across ExecutionSession and ExecutorProcessControl."

This reverts commit 6094b3b7db7eab8318b9d30dec2691d231c7bdff.

Multiple bots are broken.

[ORC] Unify task dispatch across ExecutionSession and ExecutorProcessControl.

Updates ExecutionSession to use the ExecutorProcessControl object's
TaskDispatcher rather than having a separate dispatc

[ORC] Unify task dispatch across ExecutionSession and ExecutorProcessControl.

Updates ExecutionSession to use the ExecutorProcessControl object's
TaskDispatcher rather than having a separate dispatch function. This gives the
TaskDispatcher a global view of all tasks to be executed, and provides a
single point to wait on for tasks to complete when shutting down the JIT.

show more ...

[ORC] Make EPCDynamicLibrarySearchGenerator async

Switch the primary implementation of EPC lookupSymbols to be async,
keeping a synchronous wrapper for compatibility. Use the new async
implementat

[ORC] Make EPCDynamicLibrarySearchGenerator async

Switch the primary implementation of EPC lookupSymbols to be async,
keeping a synchronous wrapper for compatibility. Use the new async
implementation inside EPCDynamicLibrarySearchGenerator to work
working towards a fully async search generator.

Provide an asynchronous lookup API for EPCGenericDylibManager and adopt
that from the SimpleRemoteEPC. This enables an end-to-end async
EPCDynamicLibrarySearchGenerator. Note: currently we keep the current
per-dlhandle lookup model, but a future improvement could do a single
async call for a given lookup operation.

show more ...

[ORC] Refactor executor symbol lookup to use ExecutorSymbolDef (NFC) (#76989)

This migrates the dylib manager lookup and related APIs to replace
ExecutorAddress with ExecutorSymbolDef so that in th

[ORC] Refactor executor symbol lookup to use ExecutorSymbolDef (NFC) (#76989)

This migrates the dylib manager lookup and related APIs to replace
ExecutorAddress with ExecutorSymbolDef so that in the future we can
model JITSymbolFlags for these symbols. The current change should be NFC
as we are only setting the Exported symbol flag.

show more ...

[ORC] Add writePointers to ExecutorProcessControl's MemoryAccess

Add pointer write functionality to MemoryAccess that is needed for implementing redirection manager. It also refactors the code a bit

[ORC] Add writePointers to ExecutorProcessControl's MemoryAccess

Add pointer write functionality to MemoryAccess that is needed for implementing redirection manager. It also refactors the code a bit by introducing InProcessMemoryAccess class.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D157378

show more ...

[ORC] Use EPC bootstrap symbols to communicate eh-frame registration fn addrs.

By using bootstrap symbols to communicate these addresseses, rather than dlsym
lookups, we no longer need them to be ex

[ORC] Use EPC bootstrap symbols to communicate eh-frame registration fn addrs.

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).

show more ...

[ORC] Move most ORC APIs to ExecutorAddr, introduce ExecutorSymbolDef.

ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for
JITTargetAddress. ExecutorSymbolDef is introduced in

[ORC] Move most ORC APIs to ExecutorAddr, introduce ExecutorSymbolDef.

ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for
JITTargetAddress. ExecutorSymbolDef is introduced in this patch as a
replacement for JITEvaluatedSymbol: ExecutorSymbolDef is an (ExecutorAddr,
JITSymbolFlags) pair, where JITEvaluatedSymbol was a (JITTargetAddress,
JITSymbolFlags) pair.

A number of APIs had already migrated from JITTargetAddress to ExecutorAddr,
but many of ORC's internals were still using the older type. This patch aims
to address that.

Some public APIs are affected as well. If you need to migrate your APIs you can
use the following operations:

* ExecutorAddr::toPtr replaces jitTargetAddressToPointer and
jitTargetAddressToFunction.

* ExecutorAddr::fromPtr replace pointerToJITTargetAddress.

* ExecutorAddr(JITTargetAddress) creates an ExecutorAddr value from a
JITTargetAddress.

* ExecutorAddr::getValue() creates a JITTargetAddress value from an
ExecutorAddr.

JITTargetAddress and JITEvaluatedSymbol will remain in JITSymbol.h for now, but
the aim will be to eventually deprecate and remove these types (probably when
MCJIT and RuntimeDyld are deprecated).

show more ...

[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC w

[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.

show more ...

[ORC] Update SelfExecutorProcessControl to allow user-supplied handles.

SelfExecutorProcessControl no longer requires that handles passed to
lookupSymbols be ones that were previously returned from

[ORC] Update SelfExecutorProcessControl to allow user-supplied handles.

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 6613f4aff85.

show more ...

[ORC] Use raw OS handle values, ExecutorAddr for EPC dylib handles.

Updates tpctypes::DylibHandle to be an ExecutorAddr (rather than a uint64_t),
and SimpleExecutorDylibManager to hold and return ra

[ORC] Use raw OS handle values, ExecutorAddr for EPC dylib handles.

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).

show more ...

[ORC][COFF] Introduce COFFVCRuntimeBootstrapper.

Introduces COFFVCRuntimeBootstrapper that loads/initialize vc runtime libraries. In COFF, we *must* jit-link vc runtime libraries as COFF relocation

[ORC][COFF] Introduce COFFVCRuntimeBootstrapper.

Introduces COFFVCRuntimeBootstrapper that loads/initialize vc runtime libraries. In COFF, we *must* jit-link vc runtime libraries as COFF relocation types have no proper way to deal with out-of-reach data symbols ragardless of linking mode. (even dynamic version msvcrt.lib have tons of static data symbols that must be jit-linked) This class tries to load vc runtime library files from msvc installations with an option to override the path.

There are some complications when dealing with static version of vc runtimes. First, they need static initializers to be ran that requires COFFPlatform support but orc runtime will not be usable before vc runtimes are fully initialized. (as orc runtime will use msvc stl libraries) COFFPlatform that will be introduced in a following up patch will collect static initializers and run them manually in host before boostrapping itself. So, the user will have to do the following.
1. Create COFFPlatform that addes static initializer collecting passes.
2. LoadVCRuntime
3. InitializeVCRuntime
4. COFFPlatform.bootstrap()
Second, the internal crt initialization function had to be reimplemented in orc side. There are other ways of doing this, but this is the simplest implementation that makes platform fully responsible for static initializer. The complication comes from the fact that crt initialization functions (such as acrt_initialize or dllmain_crt_process_attach) actually run all static initializers by traversing from `__xi_a` symbol to `__xi_z`. This requires symbols to be contiguously allocated in sections alphabetically sorted in memory, which is not possible right now and not practical in jit setting. We might ignore emission of `__xi_a` and `__xi_z` symbol and allocate them ourselves, but we have to take extra care after orc runtime boostrap has been done -- as that point orc runtime should be the one running the static initializers.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D130456

show more ...

[llvm] Use = default (NFC)

[ORC] Move CWrapperFunctionResult out of the detail:: namespace.

This type has been moved up into the llvm::orc::shared namespace.

This type was originally put in the detail:: namespace on the assu

[ORC] Move CWrapperFunctionResult out of the detail:: namespace.

This type has been moved up into the llvm::orc::shared namespace.

This type was originally put in the detail:: namespace on the assumption that
few (if any) LLVM source files would need to use it. In practice it has been
needed in many places, and will continue to be needed until/unless
OrcTargetProcess is fully merged into the ORC runtime.

show more ...

Reapply e32b1eee6aa "[ORC] Change SPSExecutorAddr serialization,..." with fixes.

This re-applies e32b1eee6aab52e2b7b75ee15e506b3e7dd30e68, which was reverted in
20675d8f7dab293172266fdde426c2173b5b3

Reapply e32b1eee6aa "[ORC] Change SPSExecutorAddr serialization,..." with fixes.

This re-applies e32b1eee6aab52e2b7b75ee15e506b3e7dd30e68, which was reverted in
20675d8f7dab293172266fdde426c2173b5b3997 due to broken unit tests. This patch
includes fixes for the tests.

show more ...

Revert "[ORC] Change SPSExecutorAddr serialization, SupportFunctionCall struct."

This reverts commit e32b1eee6aab52e2b7b75ee15e506b3e7dd30e68.

Reverting while I fix some broken unit tests.

[ORC] Change SPSExecutorAddr serialization, SupportFunctionCall struct.

SPSExecutorAddr will now be serializable to/from ExecutorAddr, rather than
uint64_t. This improves type safety when working wi

[ORC] Change SPSExecutorAddr serialization, SupportFunctionCall struct.

SPSExecutorAddr will now be serializable to/from ExecutorAddr, rather than
uint64_t. This improves type safety when working with serialized addresses.

Also updates the SupportFunctionCall to use an ExecutorAddrRange (rather than
a separate ExecutorAddr addr and uint64_t size field), and updates the
tpctypes::*Write data structures to use ExecutorAddr rather than
JITTargetAddress.

show more ...

[ORC] Shut down dispatcher in ExecutorProcessControl implementations.

f3411616896 added a task dispatcher for async handlers, but didn't add a
TaskDispatcher::shutdown call to SelfExecutorProcessCon

[ORC] Shut down dispatcher in ExecutorProcessControl implementations.

f3411616896 added a task dispatcher for async handlers, but didn't add a
TaskDispatcher::shutdown call to SelfExecutorProcessControl or SimpleRemoteEPC.
This patch adds the missing call, which ensures that we don't destroy the
dispatcher while tasks are still running.

This should fix the use-after-free crash seen in
https://lab.llvm.org/buildbot/#/builders/5/builds/13063

show more ...

Re-apply e50aea58d59, "Major JITLinkMemoryManager refactor". with fixes.

Adds explicit narrowing casts to JITLinkMemoryManager.cpp.

Honors -slab-address option in llvm-jitlink.cpp, which was accide

Re-apply e50aea58d59, "Major JITLinkMemoryManager refactor". with fixes.

Adds explicit narrowing casts to JITLinkMemoryManager.cpp.

Honors -slab-address option in llvm-jitlink.cpp, which was accidentally
dropped in the refactor.

This effectively reverts commit 6641d29b70993bce6dbd7e0e0f1040753d38842f.

show more ...