| Age | Commit message (Collapse) | Author |
|---|
|
Identified with modernize-use-equals-default.
|
|
This reverts commit 3b5842c9c41a441280100045ef62bb8a0fe7200f.
The intent of the original commit was to begin enabling asynchronous
alloation actions (calls attached to JIT'd memory initialization and
deinitialization). The asynchronous allocation actions scheme was
fleshed-out in a development branch, but ran into an issue: Functions
implementing actions are allowed to live in JIT'd code (e.g. in the ORC
runtime), but we can't genally rely on tail-call elimination kicking in.
This resulting in dealloc actions returning via stack frames that had
been deallocated, triggering segfaults.
It's possible that there are other approaches that would allow
asynchronous allocation actions to work, but they're not on the critical
path for JIT improvements so for now we'll just revert.
|
|
This gives MemoryMapper implementations a chance to allocate working
memory using the LinkGraph's allocator.
|
|
Part of ongoing work to make core ORC operations asynchronous.
This only affects the runner utilities, not the AllocationActions themselves.
The AllocationActions will be made asynchronous in a future patch.
|
|
This PR will solve the issue with leaking shared memory we have after running llvm lit test on z/OS.
In particular llvm/unittests/ExecutionEngine/Orc/SharedMemoryMapperTest.cpp was causing the leak.
|
|
|
|
Identified with misc-include-cleaner.
|
|
Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.
|
|
Fix 'use of undeclared identifier' build errors for shm_ functions on
z/OS by implementing the functionality using shmget(), shmat(), and
shmdt(). Use the BLAKE3 hash to map the name of the shared memory to a
key.
---------
Co-authored-by: Kai Nacke <kai.peter.nacke@ibm.com>
|
|
LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare
differently if one is system and one is generic on POSIX systems.
This is even more of a problem on Windows where use of the system
category is just wrong, as that is for Windows errors, which have a
completely different mapping than POSIX/generic errors. This patch fixes
one instance of this mistake in `JSONTransport.cpp`.
This patch adds `errnoAsErrorCode()` which makes it so people do not
need to think about this issue in the future. It also cleans up a lot of
usage of `errno` in LLVM and Clang.
|
|
The *Policy suffix came from the earlier MemAllocPolicy type, where it was
included to distinguish the type from a memory-allocation operation.
MemLifetime is a noun already, so the *Policy suffix is just dead weight now.
|
|
This reapplies 2cc64df0bd6a802eab592dbc282463c3e4a4281c, which was reverted in
5379c46d490640bfa80283e00240b6f1006092b4 due to bot failures.
The new patch contains fixes to ELFLinkGraphBuilder.h to better handle
non-SHT_ALLOC sections (these were being accidentally skipped in the previous
patch), and to skip SHT_NULL sections.
|
|
This reverts commit 2cc64df0bd6a802eab592dbc282463c3e4a4281c while I investigate
bot failures (e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/23081).
|
|
The original MemDeallocPolicy had two options:
* Standard: allocated memory lives until deallocated or abandoned.
* Finalize: allocated memory lives until all finalize actions have been run,
then is destroyed.
This patch introduces a new 'NoAlloc' option. NoAlloc indicates that the
section should be ignored by the JITLinkMemoryManager -- the memory manager
should allocate neither working memory nor executor address space to blocks in
NoAlloc sections. The NoAlloc option is intended to support metadata sections
(e.g. debug info) that we want to keep in the graph and have fixed up if
necessary, but don't want allocated or transmitted to the executor (or we want
that allocation and transmission to be managed manually by plugins).
Since NoAlloc blocks are ignored by the JITLinkMemoryManager they will not have
working memory allocated to them by default post-allocation. Clients wishing to
modify the content of a block in a NoAlloc section should call
`Block::getMutableMemory(LinkGraph&)` to get writable memory allocated on the
LinkGraph's allocator (this memory will exist for the lifetime of the graph).
If no client requests mutable memory prior to the fixup phase then the generic
link algorithm will do so when it encounters the first edge in any given block.
Addresses of blocks in NoAlloc sections are initialized by the LinkGraph
creator (a LinkGraphBuilder, if the graph is generated from an object file),
and should not be modified by the JITLinkMemoryManager. Plugins are responsible
for updating addresses if they add/remove content from these sections. The
meaning of addresses in NoAlloc-sections is backend/plugin defined, but for
fixup purposes they will be treated the same as addresses in Standard/Finalize
sections. References from Standard/Finalize sections to NoAlloc sections are
expected to be common (these represent metadata tracking executor addresses).
References from NoAlloc sections to Standard/Finalize sections are expected to
be rare/non-existent (they would represent JIT'd code / data tracking metadata
in the controller, which would be surprising). LinkGraphBuilders and specific
backends may impose additional constraints on edges between Standard/Finalize
and NoAlloc sections where required for correctness.
Differential Revision: https://reviews.llvm.org/D146183
|
|
Fixing -Wunused -Werror build on Android.
|
|
As briefly discussed on https://reviews.llvm.org/rG1134d3a03facccd75efc5385ba46918bef94fcb6, fix the unintended copy while iterating on Reservations and add a mutex guard, to be symmetric with other usages of Reservations.
Differential revision: https://reviews.llvm.org/D134212
|
|
|
|
Moving these types to OrcShared eliminates the need for the separate
WireProtectionFlags type.
|
|
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.
|
|
SharedMemoryMapper assumed each reservation will have its corresponding
allocations starting from the beginning. However with the introduction
of the slab allocator, there can be a possible offset from the start
from where the initialization is being performed.
This commit also simplifies the logic for finding the parent reservation
and makes the assert messages consistent.
|
|
When slab allocator is used, the MappingBase is not necessarily
the same as the original reservation base as the allocation could
be a part of the whole reservation.
In this case the original reservation address needs to be passed to
ExecutorSharedMemoryMapperService to associate the new allocation
with the original reservation.
Differential Revision: https://reviews.llvm.org/D132313
|
|
By the time SharedMemoryMapper destructor is called, the RPC
connection is no longer available causing the release() call to
always fail. Instead at this point only shared memory regions
can be unmapped safely.
Deinitializers are called and mapped memory is released at the
executor side by ExecutorSharedMemoryMapperService::shutdown()
instead. Memory can also be released earlier by calling release()
earlier before RPC connection is closed.
Differential Revision: https://reviews.llvm.org/D132313
|
|
When memory is deallocated from MapperJITLinkMemoryManager deinitialize
actions are run through mapper and in case of InProcessMapper, memory
protections of the region are reset to read/write as they were previously
changed and can be reused in future.
Differential Revision: https://reviews.llvm.org/D131768
|
|
This reverts commit 143555b2ed30746fbcc8ff84e9cef4267688f110.
|
|
When memory is deallocated from MapperJITLinkMemoryManager deinitialize
actions are run through mapper and in case of InProcessMapper, memory
protections of the region are reset to read/write as they were previously
changed and can be reused in future.
Differential Revision: https://reviews.llvm.org/D131768
|
|
This fixes warnings like these:
../lib/ExecutionEngine/Orc/MemoryMapper.cpp:364:9: warning: ignoring return value of function declared with 'warn_unused_result' attribute [-Wunused-result]
joinErrors(std::move(Err),
^~~~~~~~~~ ~~~~~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D131056
|
|
shm_open and shm_unlink are not available on Android. This commit
disables SharedMemoryMapper on Android until a better solution is
available.
https://android.googlesource.com/platform/bionic/+/refs/heads/master/docs/status.md
https://github.com/llvm/llvm-project/issues/56812
Differential Revision: https://reviews.llvm.org/D130814
|
|
MapperJITLinkMemoryManager supports executor memory management using any
implementation of MemoryMapper to do the transfer such as InProcessMapper or
SharedMemoryMapper.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D129495
|
|
...with more fixes.
The original patch was reverted in 3e9cc543f22 due to bot failures caused by
a missing dependence on librt. That issue was fixed in 32d8d23cd0, but that
commit also broke sanitizer bots due to a bug in SimplePackedSerialization:
empty ArrayRef<char>s triggered a zero-byte memcpy from a null source. The
ArrayRef<char> serialization issue was fixed in 67220c2ad7, and this patch has
also been updated with a new custom SharedMemorySegFinalizeRequest message that
should avoid serializing empty ArrayRefs in the first place.
https://reviews.llvm.org/D128544
|
|
with fixes."
This reverts commit 32d8d23cd0b2d4d010eb112dfe5216f11b2681f9.
Reason: Broke the UBSan buildbots. See more details on Phabricator:
https://reviews.llvm.org/D128544
|
|
The original commit was reverted in 3e9cc543f223 due to buildbot failures, which
should be fixed by the addition of dependencies on librt.
Differential Revision: https://reviews.llvm.org/D128544
|
|
This reverts commit 5acd471698849d9e322a29e6ca08791e8d447b7b.
Breaks shared library build with:
ld.lld-12: error: undefined symbol: shm_open
>>> referenced by ExecutorSharedMemoryMapperService.cpp:68
(/home/culrho01/llvm-project/llvm/lib/ExecutionEngine/Orc/TargetProcess/ExecutorSharedMemoryMapperService.cpp:68)
>>>
lib/ExecutionEngine/Orc/TargetProcess/CMakeFiles/LLVMOrcTargetProcess.dir/ExecutorSharedMemoryMapperService.cpp.o:(llvm::orc::rt_bootstrap::ExecutorSharedMemoryMapperService::reserve[abi:cxx11](unsigned
long))
>>> did you mean: sem_open
>>> defined in:
/usr/bin/../lib/gcc/aarch64-linux-gnu/9/../../../aarch64-linux-gnu/libpthread.so
|
|
This reverts commit 46b1a7c5f9e6841016078d32728bb0d205336df5.
Parent commit breaks shared library build, reverting both commits.
|
|
Explicitly call the -W suffixed API functions when passing wchar based
strings.
|
|
This is an implementation of orc::MemoryMapper that maps shared memory
pages in both executor and controller process and writes directly to
them avoiding transferring content over EPC. All allocations are properly
deinitialized automatically on the executor side at shutdown by the
ExecutorSharedMemoryMapperService.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D128544
|
|
implementation"
[JITLink][Orc] Add MemoryMapper interface with InProcess implementation
MemoryMapper class takes care of cross-process and in-process address space
reservation, mapping, transferring content and applying protections.
Implementations of this class can support different ways to do this such
as using shared memory, transferring memory contents over EPC or just
mapping memory in the same process (InProcessMemoryMapper).
The original patch landed with commit 6ede65205073d3cf6b1ed4d101e66eae3e0fc8e6
It was reverted temporarily in commit 6a4056ab2ada0046ff97a55a5fb34c2c59504fd1
Reviewed By: sgraenitz, lhames
Differential Revision: https://reviews.llvm.org/D127491
|
|
This reverts commit 6ede65205073d3cf6b1ed4d101e66eae3e0fc8e6.
Doesn't build on Windows, see https://reviews.llvm.org/D127491#3598773
|
|
MemoryMapper class takes care of cross-process and in-process address space
reservation, mapping, transferring content and applying protections.
Implementations of this class can support different ways to do this such
as using shared memory, transferring memory contents over EPC or just
mapping memory in the same process (InProcessMemoryMapper).
Reviewed By: sgraenitz, lhames
Differential Revision: https://reviews.llvm.org/D127491
|
