| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
RedirectableMaterializationUnit needs its own copy of this map anyway, so
passing by value allows us to potentially omit a copy.
|
|
In JITLinkRedirectableSymbolManager::redirect we no longer need to disambiguate
between the JD for the redirectable symbols and the one for the corresponding
stubs (they're the same as of 529c091381a). Renaming it brings the parameter
name into line with the one used in the base class's redirect method.
|
|
Redirectable stubs should be placed in the same JITDylib as their names, with
their lifetimes managed according to the ResourceTracker used when adding them.
The original implementation created a single pool of stubs in the JITDylib
that is passed to the JITLinkRedirectableSymbolManager constructor, but this
may cause the addresses of the redirectable symbols themselves (added to the
JITDylibs passed to createRedirectableSymbols) to appear outside the address
range of their defining JITDylib.
This patch fixes the issue by dropping the pool and emitting a new graph for
each set of requested redirectable symbols. We lose the ability to recycle
stubs, but gain the ability to free them entirely. Since we don't expect stub
reuse to be a common case this is likely the best trade-off.
If in the future we do need to return to a stub pool we should create a
separate one for each JITDylib to ensure that addresses behave as expected.
|
|
Creation of pointers and jump stubs always succeeds for all existing JITLink
backends, and I haven't been able to think of a scenario where it would fail.
(Pointer / stub *fixup* may fail due to range errors, but that will happen
later and the APIs already account for it).
|
|
Fixes compiler-rt/test/orc/TestCases/Linux/x86-64/priority-static-initializer.S
testcase after 244ea406259. This testcase had been succeeding because the
definition order of the .init_array sections in the testcase matched their
priorities, but began failing once 244ea406259 removed that guarantee. The
proper fix is to visit the .init_array sections according to their priority
order, regardless of how they're defined in the file.
This fixes the single-file testcase, but I think that ELFNixPlatform will need
to be extended to make priorities work correctly across file boundaries.
|
|
When transferring resources, the destination tracker key may not be in
the internal map, invalidating iterators and value references. The added
test creates such situation and would fail before with "Finalized
allocation was not deallocated."
For good measure, fix the same pattern in RTDyldObjectLinkingLayer
which is harder to test because it "only" results in memory managers
being deleted in the wrong order.
|
|
|
|
The getMachODefaultTextSection and getMachODefaultRWDataSection functions
return the "__TEXT,__text" and "__DATA,__data" sections respectively, creating
empty sections if the default sections are not already present in the graph.
These functions can be used by utilities that want to add code or data to these
standard sections (e.g. these functions can be used to supply the section
argument to the createAnonymousPointerJumpStub and
createPointerJumpStubBlock functions in the various targets).
|
|
|
|
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).
|
|
Add sign extension on i32 return value.
|
|
|
|
The atexit needs a signext attribute on its return type. See
https://github.com/llvm/llvm-project/issues/109658.
|
|
This patch adds support for forced loading of archive members, similar to the
behavior of the -all_load and -ObjC options in ld64. To enable this, the
StaticLibraryDefinitionGenerator class constructors are extended with a
VisitMember callback that is called on each member file in the archive at
generator construction time. This callback can be used to unconditionally add
the member file to a JITDylib at that point.
To test this the llvm-jitlink utility is extended with -all_load (all platforms)
and -ObjC (darwin only) options. Since we can't refer to symbols in the test
objects directly (these would always cause the member to be linked in, even
without the new flags) we instead test side-effects of force loading: execution
of constructors and registration of Objective-C metadata.
rdar://134446111
|
|
factory & constructor (#112419)
We can get a reference to the `ExecutionSession` from the
`ObjectLinkingLayer` argument, so there's no need to pass it in
separately.
This mirrors recent changes to `ElfNixPlatform` and `MachOPlatform` by
@lhames in
https://github.com/llvm/llvm-project/commit/3dba4ca155e0b460ca82917b25d3624eb5825940
and
https://github.com/llvm/llvm-project/commit/cc20dd285ab72292a1d383d0779aecbe5e1ccf81.
|
|
|
|
|
|
|
|
We can get a reference to the ExecutionSession from the ObjectLinkingLayer
argument, so there's no need to pass it in separately.
|
|
We can get a reference to the ExecutionSession from the ObjectLinkingLayer
argument, so there's no need to pass it in separately.
|
|
We can get a reference to the ExecutionSession from the ObjectLinkingLayer
argument, so there's no need to pass it in separately.
|
|
|
|
|
|
Initializers (#102846)
With the help of @lhames, this PR introduces a push-request model to manage
initializers in the runtime state for each `JITDylib`, similar to how `MachO`
and `COFF` handle it. Previously, the ELF runtime lacked the ability to
register, deregister, or retain initializers, causing issues when re-running
`dlopen`. Initializers were erased after `rt_getInitializers` was used.
To address this, we introduce `__orc_rt_elfnix_register_init_sections` and
`__orc_rt_elfnix_register_jitdylib` (and corresponding deregister functions).
This model allows the runtime to request the push of initializers for the
`JITDylib`, with the platform handling this via a record method. Additionally,
we leverage `MachO`'s `RecordSectionsTracker` to store initializers, ensuring
only newly updated initializers are executed using `processNewSections`,
improving the runtime's efficiency and reliability.
|
|
Instead, when a MaterializationResponsibility contains an initializer symbol,
the Platform classes (MachO, COFF, ELFNix) will now add a defined symbol with
the same name to an arbitary block within the initializer sections, and then
add keep-alive edges from that symbol to all other init section blocks.
ObjectLinkingLayer is updated to automatically discard symbols where the
corresponding MaterializationResponsibility entry has the
MaterializationSideEffecstsOnly flag. This change simplifies both the
ObjectLinkingLayer::Plugin interface and the dependence tracking algorithm,
which no longer needs a special case for "synthetic"
(MaterializationSideEffectsOnly) symbols.
|
|
ObjectLinkingLayer::registerDependencies used to propagate external symbol
dependencies (dependencies on symbols outside the current graph) to all nodes.
Since ebe8733a11e, which merged addDependencies into notifyEmitted, the
notifyEmitted function will propagate intra-graph dependencies, so
registerDependencies no longer needs to do this.
This patch updates ObjectLinkingLayer::registerDependencies to just propagate
named dependencies (on both internal and external symbols) through anonymous
blocks, leaving the rest of the work to ExecutionSession::notifyEmitted.
It also choses a key symbol to use for blocks containing multiple symbols. The
result is both easier to read and faster.
|
|
Avoid excess layer of indirection.
|
|
With the help of @lhames, This pull request introduces the `dlupdate`
function in the ORC runtime. `dlupdate` enables incremental execution of
new initializers introduced in the REPL environment. Unlike traditional
`dlopen`, which manages initializers, code mapping, and library
reference counts, `dlupdate` focuses exclusively on running new
initializers.
|
|
Dependant lists hold raw pointers back to EDUs that depend on them. We need to
remove these entries before destroying the EDU or we'll be left with a dangling
reference that can result in use-after-free bugs.
No testcase: This has only been observed in multi-threaded setups that
reproduce the issue inconsistently.
rdar://135403614
|
|
In certain pathological object files we were getting extremely slow
linking because we were repeatedly propogating dependencies to the same
blocks instead of accumulating as many changes as possible. Change the
order of iteration so that we go through every node in the worklist
before returning to any previous node, reducing the number of expensive
dependency iterations.
In practice, this took one case from 60 seconds to 2 seconds. Note: the
performance is still non-deterministic, because the block order itself
is non-deterministic.
rdar://133734391
|
|
Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.
|
|
|
|
This allows us to rewrite part of StaticLibraryDefinitionGenerator in terms of
loadLinkableFile.
It's also useful for clients who may not know (either from file extensions or
context) whether a given path will be an object file, an archive, or a
universal binary.
rdar://134638070
|
|
`JITDylibSearchOrderResolver` local variable can be destroyed before
completion of all callbacks. Capture it together with `Deps` in
`OnEmitted` callback.
Original error:
```
==2035==ERROR: AddressSanitizer: stack-use-after-return on address 0x7bebfa155b70 at pc 0x7ff2a9a88b4a bp 0x7bec08d51980 sp 0x7bec08d51978
READ of size 8 at 0x7bebfa155b70 thread T87 (tf_xla-cpu-llvm)
#0 0x7ff2a9a88b49 in operator() llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:58
#1 0x7ff2a9a88b49 in __invoke<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:149:25
#2 0x7ff2a9a88b49 in __call<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:224:5
#3 0x7ff2a9a88b49 in operator() libcxx/include/__functional/function.h:210:12
#4 0x7ff2a9a88b49 in void std::__u::__function::__policy_invoker<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr,
```
|
|
This allows clients to check buffers that they don't own.
rdar://133536831
|
|
API clients may want to use things other than paths as the buffer identifiers.
No testcase -- I haven't thought of a good way to expose this via the regression
testing tools.
rdar://133536831
|
|
Commit 3e1d4ec671 introduced a dependence on BinaryFormat, but CMakeLists.txt
was not updated to include it.
|
|
ORC supports loading relocatable object files into a JIT'd process. The
raw "add object file" API (ObjectLayer::add) accepts plain relocatable
object files as llvm::MemoryBuffers only and does not check that the
object file's format or architecture are compatible with the process
that it will be linked in to. This API is flexible, but places the
burden of error checking and universal binary support on clients.
This commit introduces a new utility, loadRelocatableObject, that takes
a path to load and a target triple and then:
1. If the path does not exist, returns a FileError containing the
invalid path.
2. If the path points to a MachO universal binary, identifies and
returns MemoryBuffer covering the slice that matches the given triple
(checking that the slice really does contains a valid MachO relocatable
object with a compatible arch).
3. If the path points to a regular relocatable object file, verifies
that the format and architecture are compatible with the triple.
Clients can use loadRelocatableObject in the common case of loading
object files from disk to simplify their code.
Note: Error checking for ELF and COFF is left as a FIXME.
rdar://133653290
|
|
In 93509b4462a74 MachOPlatform was updated to store object symbols in a shared
vector during bootstrap (this table is later attached to the
bootstrap-completion graph once the ORC runtime's symbol table registration
code is ready). The shared vector was not guarded with a mutex, so use of a
concurrent dispatcher could lead to races during bootstrap. This commit fixes
the issue by guarding access to the table with the BootstrapInfo mutex.
No testcase since this only manifests rarely when both a concurrent dispatcher
and the ORC runtime are used. Once we add a concurrent dispatcher option to
llvm-jitlink we may be able to test this with a regression test in the ORC
runtime and TSan enabled.
rdar://133520308
|
|
Seemed nicer than inlining, given the complexities of flag checking and
the multiple uses.
|
|
This reapplies 785d376d123, which was reverted in c49837f5f68 due to bot
failures. The fix was to relax some asserts to allow common symbols to be
resolved with either common or weak flags, rather than requiring one or the
other.
|
|
This reverts commit 785d376d1231167688dd12f93c5c0a5d46cd4086 while I
investigate some bot failures (e.g.
https://lab.llvm.org/buildbot/#/builders/3/builds/1983).
|
|
Duplicate common definitions should be coaleseced, rather than being treated as
duplicate definitions. Strong definitions should override common definitions.
rdar://132314264
|
|
(#99407)
Changes "MyObj.o" to "/path/to/libMyLib.a(MyObj.o)".
This allows us to differentiate between objects that have the same
basename but came from different archives. It also fixes a bug where if
two such objects were both linked and both have initializer sections
their initializer symbol would cause a duplicate symbol error.
rdar://131782514
|
|
Previously this took a reference to a map and returned a bool to say
whether it succeeded. We can return a StringMap instead, as all callers
but 1 simply iterated the map if the bool was true, and passed in empty
maps as the starting point.
lldb's lit-cpuid did specifically check whether the call failed, but due
to the way the x86 routines work this works out the same as checking if
the returned map is empty.
|
|
This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
std::unique_ptr<Type>(new Type()), which is a bit mouthful.
|
|
This used to be necessary to fetch the DataLayout, but isn't anymore.
|
|
Replace it with a forward declaration instead. Analysis.h is pulled in
by all passes, but not all passes need to access the module.
|
|
(#88115) (#90599)
Closes #88115
|
|
Similar to https://github.com/llvm/llvm-project/pull/96902, this adds
`getDataLayout()` helpers to Function and GlobalValue, replacing the
current `getParent()->getDataLayout()` pattern.
|
