|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
e9014d97 |
| 01-Nov-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
4fcc0ac1 |
| 13-Oct-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
2815ed57 |
| 12-Oct-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
17a0858f |
| 11-Oct-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
a6c95063 |
| 11-Oct-2021 |
Stefan Gränitz <[email protected]> |
[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 ...
|
| #
4d7cea3d |
| 10-Oct-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
da7f993a |
| 10-Oct-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
21a06254 |
| 27-Sep-2021 |
Lang Hames <[email protected]> |
[ORC] Switch from JITTargetAddress to ExecutorAddr for EPC-call APIs.
Part of the ongoing move to ExecutorAddr.
|
| #
4b37462a |
| 27-Sep-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
175c1a39 |
| 26-Sep-2021 |
Lang Hames <[email protected]> |
[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.
|
| #
320832cc |
| 26-Sep-2021 |
Lang Hames <[email protected]> |
[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 ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
| #
ef391df2 |
| 23-Sep-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
a2c1cf09 |
| 22-Sep-2021 |
Lang Hames <[email protected]> |
[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 ...
|
|
Revision tags: llvmorg-13.0.0-rc3 |
|
| #
78b083db |
| 14-Sep-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
2c8e7849 |
| 13-Sep-2021 |
Lang Hames <[email protected]> |
[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 ...
|
| #
b64fc0af |
| 12-Sep-2021 |
Lang Hames <[email protected]> |
[ORC] Add bootstrap symbols to ExecutorProcessControl.
Bootstrap symbols are symbols whose addresses may be required to bootstrap the rest of the JIT. The bootstrap symbols map generalizes the exist
[ORC] Add bootstrap symbols to ExecutorProcessControl.
Bootstrap symbols are symbols whose addresses may be required to bootstrap the rest of the JIT. The bootstrap symbols map generalizes the existing JITDispatchInfo class provide an arbitrary map of symbol names to addresses.
The JITDispatchInfo class will be replaced by bootstrap symbols with reserved names in upcoming commits.
show more ...
|
| #
d11a0c5d |
| 12-Sep-2021 |
Lang Hames <[email protected]> |
[ORC] Fix out-of-range comparison errors.
|
| #
bb72f073 |
| 11-Sep-2021 |
Lang Hames <[email protected]> |
Re-apply bb27e456435 and 5629afea910 with fixes.
This reapplies bb27e4564355243e479cab40885d6e0f7f640572 (SimpleRemoteEPC support) and 2269a941a450a0d395161cfb792be58870b2875b (#include <mutex> fix)
Re-apply bb27e456435 and 5629afea910 with fixes.
This reapplies bb27e4564355243e479cab40885d6e0f7f640572 (SimpleRemoteEPC support) and 2269a941a450a0d395161cfb792be58870b2875b (#include <mutex> fix) with further fixes to support building with LLVM_ENABLE_THREADS=Off.
show more ...
|
| #
bb27e456 |
| 07-Sep-2021 |
Lang Hames <[email protected]> |
[ORC] Add SimpleRemoteEPC: ExecutorProcessControl over SPS + abstract transport.
SimpleRemoteEPC is an ExecutorProcessControl implementation (with corresponding new server class) that uses ORC Simpl
[ORC] Add SimpleRemoteEPC: ExecutorProcessControl over SPS + abstract transport.
SimpleRemoteEPC is an ExecutorProcessControl implementation (with corresponding new server class) that uses ORC SimplePackedSerialization (SPS) to serialize and deserialize EPC-messages to/from byte-buffers. The byte-buffers are sent and received via a new SimpleRemoteEPCTransport interface that can be implemented to run SimpleRemoteEPC over whatever underlying transport system (IPC, RPC, network sockets, etc.) best suits your use case.
The SimpleRemoteEPCServer class provides executor-side support. It uses a customizable SimpleRemoteEPCServer::Dispatcher object to dispatch wrapper function calls to prevent the RPC thread from being blocked (a problem in some earlier remote-JIT server implementations). Almost all functionality (beyond the bare basics needed to bootstrap) is implemented as wrapper functions to keep the implementation simple and uniform.
Compared to previous remote JIT utilities (OrcRemoteTarget*, OrcRPCExecutorProcessControl), more consideration has been given to disconnection and error handling behavior: Graceful disconnection is now always initiated by the ORC side of the connection, and failure at either end (or in the transport) will result in Errors being delivered to both ends to enable controlled tear-down of the JIT and Executor (in the Executor's case this means "as controlled as the JIT'd code allows").
The introduction of SimpleRemoteEPC will allow us to remove other remote-JIT support from ORC (including the legacy OrcRemoteTarget* code used by lli, and the OrcRPCExecutorProcessControl and OrcRPCEPCServer classes), and then remove ORC RPC itself.
The llvm-jitlink and llvm-jitlink-executor tools have been updated to use SimpleRemoteEPC over file descriptors. Future commits will move lli and other tools and example code to this system, and remove ORC RPC.
show more ...
|