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.
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.
The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.
For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.
The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.
This re-applies f905bf3e1ef860c4d6fe67fb64901b6bbe698a91, which was reverted in
c861c1a046eb8c1e546a8767e0010904a3c8c385 due to compiler errors, with a fix for
MLIR.
Signing a null pointer value can, and usually will, result in some high bits
being set, causing null checks to fail. E.g. in
extern void __attribute__((weak_import)) f(void);
void (*p) = &f;
if f is undefined then p should be null (left unsigned).
This patch updates lowerPointer64AuthEdgesToSigningFunction to check for
Pointer64Authenticated edges to null targets. Where found, these edges are
turned into plain Pointer64 edges (which we know from context will write a null
value to the fixup location), and signing instructions for these locations are
omitted from the signing function.
MachOPlatform synthesizes Mach headers for JITDylibs (see ef314d39b92). This
commit adds support for adding LC_LOAD_WEAK_DYLIB commands to these synthesized
headers (LC_LOAD_DYLIB was already supported previously).
Commit 253e11695ba added support for emulating weak-linking against dylibs
that are (under the emulation) absent at runtime. This commit extends emulated
weak linking support to allow a real dylib to supply the interface (i.e.
-weak-lx / -weak_library can be pointed at a dylib, in which case they should
be read as "weak-link against this dylib, behavining as if it weren't actually
present at runtime").
Linking libraries in ld64 with -weak-lx / -weak_library causes all references
to symbols in those libraries to be made weak, allowing the librarie to be
missing at runtime.
This patch extends EPCDynamicLibrarySearchGenerator with support for emulating
this behavior: If an instance is constructed with an Allow predicate but no
dylib handle then all symbols matching the predicate are immediately resolved
to null.
The llvm-jitlink tool is updated with -weak-lx / -weak_library options for
testing. Unlike their ld64 counterparts these options take a TBD file as input,
and always resolve all exports in the TBD file to null.
Updates JITLinkRedirectableSymbolManager to take alias flags into account when
setting the scope and linkage of the created stubs (weak aliases get now get weak
linkage, hidden stubs get hidden visibility).
Updates lazyReexports to propagate alias flags (rather than trampoline flags)
when building the initial destinations map for the redirectable symbols manager.
Together these changes allow the LazyObjectLinkingLayer to link objects
containing weak and hidden symbols.
The find-dynamic-unwind-info callback registration APIs in libunwind
limit the number of callbacks that can be registered. If we use multiple
UnwindInfoManager instances, each with their own own callback function
(as was the case prior to this patch) we can quickly exceed this limit
(see https://github.com/llvm/llvm-project/issues/126611).
This patch updates the UnwindInfoManager class to use a singleton
pattern, with the single instance shared between all LLVM JITs in the
process.
This change does _not_ apply to compact unwind info registered through
the ORC runtime (which currently installs its own callbacks).
As a bonus this change eliminates the need to load an IR "bouncer"
module to supply the unique callback for each instance, so support for
compact-unwind can be extended to the llvm-jitlink tools (which does not
support adding IR).
The system libunwind on older Darwins does not support JIT registration of
compact-unwind. Since the CompactUnwindManager utility discards redundant
eh-frame FDEs by default we need to remove the compact-unwind section first
when targeting older libunwinds in order to preserve eh-frames.
While LLJIT was already doing this as of eae6d6d18bd, MachOPlatform was not.
This was causing buildbot failures in the ORC runtime (e.g. in
https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/3479/).
This patch updates both LLJIT and MachOPlatform to check a bootstrap value,
"darwin-use-ehframes-only", to determine whether to forcibly preserve
eh-frame sections. If this value is present and set to true then compact-unwind
sections will be discarded, causing eh-frames to be preserved. If the value is
absent or set to false then compact-unwind will be used and redundant FDEs in
eh-frames discarded (FDEs that are needed by the compact-unwind section are
always preserved).
rdar://143895614
