[ORC] Provide default MemoryAccess in SimpleRemoteEPC, add WritePointers impl.

Make EPCGenericMemoryAccess the default implementation for the MemoryAccess
object in SimpleRemoteEPC, and add support

[ORC] Provide default MemoryAccess in SimpleRemoteEPC, add WritePointers impl.

Make EPCGenericMemoryAccess the default implementation for the MemoryAccess
object in SimpleRemoteEPC, and add support for the WritePointers operation to
OrcTargetProcess (previously this operation was unimplemented and would have
triggered an error if accessed in a remote-JIT setup).

No testcase yet: This functionality requires cross-process JITing to test (or a
much more elaborate unit-test setup). It can be tested once the new top-level
ORC runtime project lands.

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

[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] Add a generic bootstrap key-value store to SimpleRemoteEPC.

SimpleRemoteEPC already included a "bootstrap symbols map" that could be used
to communicate the addresses of symbols needed for JIT

[ORC] Add a generic bootstrap key-value store to SimpleRemoteEPC.

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

show more ...

[ORC] Remove redundant ExecutorAddr temporaries.

Most ORC APIs work with ExecutorAddr by default since 8b1771bd9f3, so we don't
need to wrap these values in ExecutorAddr(...) calls any more.

[ORC] Simplify some ExecutorAddr uses by removing getValue and formatv.

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

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

[ORC] Run incoming jit-dispatch calls via the TaskDispatcher in SimpleRemoteEPC.

Handlers for jit-dispatch calls are allowed to make their own EPC calls, so we
don't want to run these on the handler

[ORC] Run incoming jit-dispatch calls via the TaskDispatcher in SimpleRemoteEPC.

Handlers for jit-dispatch calls are allowed to make their own EPC calls, so we
don't want to run these on the handler thread.

show more ...

[ORC] Use a Setup object for SimpleRemoteEPC construction.

SimpleRemoteEPC notionally allowed subclasses to override the
createMemoryManager and createMemoryAccess methods to use custom objects, but

[ORC] Use a Setup object for SimpleRemoteEPC construction.

SimpleRemoteEPC notionally allowed subclasses to override the
createMemoryManager and createMemoryAccess methods to use custom objects, but
could not actually be subclassed in practice (The construction process in
SimpleRemoteEPC::Create could not be re-used).

Instead of subclassing, this commit adds a SimpleRemoteEPC::Setup class that
can be used by clients to set up the memory manager and memory access members.
A default-constructed Setup object results in no change from previous behavior
(EPCGeneric* memory manager and memory access objects used by default).

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

[ORC] Propagate errors to handlers when sendMessage fails.

In SimpleRemoteEPC, calls to from callWrapperAsync to sendMessage may fail.
The handlers may or may not be sent failure messages by handleD

[ORC] Propagate errors to handlers when sendMessage fails.

In SimpleRemoteEPC, calls to from callWrapperAsync to sendMessage may fail.
The handlers may or may not be sent failure messages by handleDisconnect,
depending on when that method is run. This patch adds a check for an un-failed
handler, and if it finds one sends it a failure message.

show more ...

[Orc] Handle hangup messages in SimpleRemoteEPC

On the controller-side, handle `Hangup` messages from the executor. The executor passed `Error::success()` or a failure message as payload.

Hangups c

[Orc] Handle hangup messages in SimpleRemoteEPC

On the controller-side, handle `Hangup` messages from the executor. The executor passed `Error::success()` or a failure message as payload.

Hangups cause an immediate disconnect of the transport layer. The disconnect function may be called later again and so implementations should be prepared. `FDSimpleRemoteEPCTransport::disconnect()` already has a flag to check that:
https://github.com/llvm/llvm-project/blob/cd1bd95d8707371da0e4f75cd01669c427466931/llvm/lib/ExecutionEngine/Orc/Shared/SimpleRemoteEPCUtils.cpp#L112

Reviewed By: lhames

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

show more ...

[ORC] Add optional RunPolicy to ExecutorProcessControl::callWrapperAsync.

The callWrapperAsync and callSPSWrapperAsync methods take a handler object
that is run on the return value of the call when

[ORC] Add optional RunPolicy to ExecutorProcessControl::callWrapperAsync.

The callWrapperAsync and callSPSWrapperAsync methods take a handler object
that is run on the return value of the call when it is ready. The new RunPolicy
parameters allow clients to control how these handlers are run. If no policy is
specified then the handler will be packaged as a GenericNamedTask and dispatched
using the ExecutorProcessControl's TaskDispatch member. Callers can use the
ExecutorProcessControl::RunInPlace policy to cause the handler to be run
directly instead, which may be preferrable for simple handlers, or they can
write their own policy object (e.g. to dispatch as some other kind of Task,
rather than GenericNamedTask).

show more ...

[ORC] Reorder callWrapperAsync and callSPSWrapperAsync parameters.

The callee address is now the first parameter and the 'SendResult' function
the second. This change improves consistentency with th

[ORC] Reorder callWrapperAsync and callSPSWrapperAsync parameters.

The callee address is now the first parameter and the 'SendResult' function
the second. This change improves consistentency with the non-async functions
where the callee is the first address and the return value the second.

show more ...

[ORC] Switch from JITTargetAddress to ExecutorAddr for EPC-call APIs.

Part of the ongoing move to ExecutorAddr.

[ORC] Fix SimpleRemoteEPC data races.

Adds a 'start' method to SimpleRemoteEPCTransport to defer transport startup
until the client has been configured. This avoids races on client members if the
fi

[ORC] Fix SimpleRemoteEPC data races.

Adds a 'start' method to SimpleRemoteEPCTransport to defer transport startup
until the client has been configured. This avoids races on client members if the
first messages arrives while the client is being configured.

Also fixes races on the file descriptors in FDSimpleRemoteEPCTransport.

show more ...

[ORC][llvm-jitlink] Add debugging output to SimpleRemoteEPC (and Server).

Also adds an optional 'debug' argument to the llvm-jitlink-executor tool to
enable debug-logging.

[ORC] Wait for handleDisconnect to complete in SimpleRemoteEPC::disconnect.

Disconnect should block until handleDisconnect completes, otherwise we might
destroy the SimpleRemoteEPC instance while it

[ORC] Wait for handleDisconnect to complete in SimpleRemoteEPC::disconnect.

Disconnect should block until handleDisconnect completes, otherwise we might
destroy the SimpleRemoteEPC instance while it's still in use.

Thanks to Dave Blaikie for helping me track this down.

show more ...

[ORC] Rename ExecutorAddress to ExecutorAddr.

Removing the 'ess' suffix improves the ergonomics without sacrificing clarity.
Since this class is likely to be used more frequently in the future it's

[ORC] Rename ExecutorAddress to ExecutorAddr.

Removing the 'ess' suffix improves the ergonomics without sacrificing clarity.
Since this class is likely to be used more frequently in the future it's worth
some short term pain to fix this now.

show more ...

[ORC] Introduce EPCGenericDylibManager / SimpleExecutorDylibManager.

EPCGenericDylibManager provides an interface for loading dylibs and looking up
symbols in the executor, implemented using EPC-cal

[ORC] Introduce EPCGenericDylibManager / SimpleExecutorDylibManager.

EPCGenericDylibManager provides an interface for loading dylibs and looking up
symbols in the executor, implemented using EPC-calls to functions in the
executor.

SimpleExecutorDylibManager is an executor-side service that provides the
functions used by EPCGenericDylibManager.

SimpleRemoteEPC is updated to use an EPCGenericDylibManager instance to
implement the ExecutorProcessControl loadDylib and lookup methods. In a future
commit these methods will be removed, and clients updated to use
EPCGenericDylibManagers directly.

show more ...

[ORC] Add finalization & deallocation actions, SimpleExecutorMemoryManager class

Finalization and deallocation actions are a key part of the upcoming
JITLinkMemoryManager redesign: They generalize t

[ORC] Add finalization & deallocation actions, SimpleExecutorMemoryManager class

Finalization and deallocation actions are a key part of the upcoming
JITLinkMemoryManager redesign: They generalize the existing finalization and
deallocate concepts (basically "copy-and-mprotect", and "munmap") to include
support for arbitrary registration and deregistration of parts of JIT linked
code. This allows us to register and deregister eh-frames, TLV sections,
language metadata, etc. using regular memory management calls with no additional
IPC/RPC overhead, which should both improve JIT performance and simplify
interactions between ORC and the ORC runtime.

The SimpleExecutorMemoryManager class provides executor-side support for memory
management operations, including finalization and deallocation actions.

This support is being added in advance of the rest of the memory manager
redesign as it will simplify the introduction of an EPC based
RuntimeDyld::MemoryManager (since eh-frame registration/deregistration will be
expressible as actions). The new RuntimeDyld::MemoryManager will in turn allow
us to remove older remote allocators that are blocking the rest of the memory
manager changes.

show more ...

[ORC] Add Shared/OrcRTBridge, and TargetProcess/OrcRTBootstrap.

This is a small first step towards reorganization of the ORC libraries:

Declarations for types and function names (as strings) to be

[ORC] Add Shared/OrcRTBridge, and TargetProcess/OrcRTBootstrap.

This is a small first step towards reorganization of the ORC libraries:

Declarations for types and function names (as strings) to be found in the
"ORC runtime bootstrap" set are moved into OrcRTBridge.h / OrcRTBridge.cpp.

The current implementation of the "ORC runtime bootstrap" functions is moved
into OrcRTBootstrap.h and OrcRTBootstrap.cpp. It is likely that this code will
eventually be moved into ORT-RT proper (in compiler RT).

The immediate goal of this change is to make these bootstrap functions usable
for clients other than SimpleRemoteEPC/SimpleRemoteEPCServer. The first planned
client is a new RuntimeDyld::MemoryManager that will run over EPC, which will
allow us to remove the old OrcRemoteTarget code.

show more ...