`RTDyldObjectLinkingLayer` is currently creating a memory manager
without any parameters.
In this PR I am passing the MemoryBuffer that will be emitted to the
MemoryManager so that the user can use it to configure the behaviour of
the MemoryManager.
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/ExecutionEngine`
library. These annotations currently have no meaningful impact on the
LLVM build; however, they are a prerequisite to support an LLVM Windows
DLL (shared library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
The bulk of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.
The following manual adjustments were also applied after running IDS on
Linux:
- Add `LLVM_ABI_FRIEND` to friend member functions declared with
`LLVM_ABI`
- Add `LLVM_ABI` to a subset of private class methods and fields that
require export
- Add `LLVM_ABI` to a small number of symbols that require export but
are not declared in headers
- Add `LLVM_ABI` to a number of `extern "C"` methods that IDS missed
because they're implicitly exported
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
MachOPlatform::BootstrapInfo::Mutex was meant to be used to synchronize access
to the MachOPlatform::BootstrapInfo::ActiveGraphs member, but the latter was
also modified under the MachOPlatform::PlatformMutex (in
MachOPlatform::MachOPlatformPlugin::modifyPassConfig), leading to a data race.
There have been external reports (rdar://151041549) of deadlocks on the
MachOPlatform::BootstrapInfo::CV condition variable that are consistent with
corruption of the ActiveGraphs member (though alternative explanations for
the reported behavior exist, and it has been too rare in practice to verify).
This patch removes the misused MachOPlatform::BootstrapInfo::Mutex member and
synchronizes all accesses to ActiveGraphs using MachOPlatform::PlatformMutex
instead. Since ActiveGraphs is only used during bootstrap the performance
impact of this should be negligible.
rdar://151041549 - possible fix.
This reapplies b0979b8c65d, which was reverted in 370aecb9572 due to bot
failures. The failures were caused by typos in the testcase that are fixed in
this patch.
This refactor was motivated by two bugs identified in out-of-tree
builds:
1. Some implementations of the VisitMembersFunction type (often used to
implement special loading semantics, e.g. -all_load or -ObjC) were assuming
that buffers for archive members were null-terminated, which they are not in
general. This was triggering occasional assertions.
2. Archives may include multiple members with the same file name, e.g.
when constructed by appending files with the same name:
% llvm-ar crs libfoo.a foo.o
% llvm-ar q libfoo.a foo.o
% llvm-ar t libfoo.a foo.o
foo.o
While confusing, these members may be safe to link (provided that they're
individually valid and don't define duplicate symbols). In ORC however, the
archive member name may be used to construct an ORC initializer symbol,
which must also be unique. In that case the duplicate member names lead to a
duplicate definition error even if the members define unrelated symbols.
In addition to these bugs, StaticLibraryDefinitionGenerator had grown a
collection of all member buffers (ObjectFilesMap), a BumpPtrAllocator
that was redundantly storing synthesized archive member names (these are
copied into the MemoryBuffers created for each Object, but were never
freed in the allocator), and a set of COFF-specific import files.
To fix the bugs above and simplify StaticLibraryDefinitionGenerator this
patch makes the following changes:
1. StaticLibraryDefinitionGenerator::VisitMembersFunction is generalized
to take a reference to the containing archive, and the index of the
member within the archive. It now returns an Expected<bool> indicating
whether the member visited should be treated as loadable, not loadable,
or as invalidating the entire archive.
2. A static StaticLibraryDefinitionGenerator::createMemberBuffer method
is added which creates MemoryBuffers with unique names of the form
`<archive-name>[<index>](<member-name>)`. This defers construction of
member names until they're loaded, allowing the BumpPtrAllocator (with
its redundant name storage) to be removed.
3. The ObjectFilesMap (symbol name -> memory-buffer-ref) is replaced
with a SymbolToMemberIndexMap (symbol name -> index) which should be
smaller and faster to construct.
4. The 'loadability' result from VisitMemberFunctions is now taken into
consideration when building the SymbolToMemberIndexMap so that members
that have already been loaded / filtered out can be skipped, and do not
take up any ongoing space.
5. The COFF ImportedDynamicLibraries member is moved out into the
COFFImportFileScanner utility, which can be used as a
VisitMemberFunction.
This fixes the bugs described above; and should lower memory consumption
slightly, especially for archives with many files and / or symbol where
most files are eventually loaded.
The context string can be added to indicate the source of the duplicate
definition. E.g. if the context is set to "foo2.o", then:
"Duplicate definition of symbol 'foo'"
becomes
"In foo2.o, duplicate definition of symbol 'foo'".
The JITDylib::defineImpl method is updated to use the name of the
MaterializationUnit being added as the context string for duplicate definition
errors. The JITDylib::defineMaterializing method is updated to use
"defineMaterializing operation" as the conext string.
When building on i386, both clang and gcc define a builtin 'i386' macro (see
discussion in https://github.com/llvm/llvm-project/pull/137063). This causes
build errors in the JITLink/i386 backend when attempting to build LLVM on i386.
This commit renames the 'i386' backend (namespaces, APIs and files) to 'x86' to
avoid this issue.
R_386_GOT32 was already handled by lowering to
EdgeKind_i386::RequestGOTAndTransformToDelta32FromGOT. R_386_GOT32X is just an
optionally relaxable version of R_386_GOT32, so we can lower to the same edge
kind.
I've left a TODO to add a relaxable edge kind and update the i386 relaxation
optimization in the future, though I'll probably leave this as an exercise for
any i386 aficionados out there. ;)
After upgrading the default code model from small to medium on
LoongArch, function calls using expression may fail. This is because the
function call instruction has changed from `bl` to `pcalau18i + jirl`,
but `RuntimeDyld` does not handle out-of-range jumps for this
instruction sequence.
This patch fixes: #136561
Reviewed By: SixWeining
Pull Request: https://github.com/llvm/llvm-project/pull/136563
This patch replaces:
llvm::copy(Src, std::back_inserter(Dst));
with:
llvm::append_range(Dst, Src);
for breavity.
One side benefit is that llvm::append_range eventually calls
llvm::SmallVector::reserve if Dst is of llvm::SmallVector.
After implementing CFI instructions in the function prologue, LLDB
testing for RISC-V started failing due to insufficient relocations
(e.g., R_RISCV_SET8, R_RISCV_SET16).
This patch adds support for the necessary RISC-V relocations in MCJIT.
Ptrauth relocations can only be fixed up in the executing process, but noalloc
sections do not have any memory in the executing process. Failure to skip
ptrauth edges results in signing instructions that operate on invalid addresses,
leading to segfaults or data corruption.
Ignoring noalloc sections for ptrauth lowering purposes allows the ptrauth
edges to persist until they reach the applyFixup method, at which point they
raise a useful error and cleanly terminate linking.
The JITLinkMemoryManager::InFlightAlloc::abandon method should only abandon
memory for the current allocation, not any other allocations. In
MapperJITLinkMemoryManager this corresponds to the deinitialize operation, not
the deallocate operation (which releases whole slabs of memory that may be
shared by many allocations).
No testcase: This was spotted by inspection. The failing program was linking
concurrently when one linker instance raised an error. Through the call to
abandon an entire underlying slab was deallocated, resulting in segfaults in
other concurrent links that were sharing that slab.
Reverts llvm/llvm-project#132587
Due to causing test failures on several of Linaro's buildbots. Several
MLIR test failures and at least one test timing out.
I doubt it's the patch itself, but instead an issue it has uncovered.
Revert while we dig into that.
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
In some cases, we can further fold that into the set declaration.
Currently, `DIContext::getLineInfoForAddress` and
`DIContext::getLineInfoForDataAddress` returns empty DILineInfo when the
debug info is missing for the given address. This is not differentiable
with the case when debug info is found for the given address but the
debug info is default value (filename:linenum is <invalid>:0).
This change wraps the return types of `DIContext::getLineInfoForAddress`
and `DIContext::getLineInfoForDataAddress` with `std::optional`.
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.
