[ORC] Add MaterializationUnit::Interface parameter to ObjectLayer::add.

Also moves object interface building functions out of Mangling.h and in to the
new ObjectFileInterfaces.h header, and updates

[ORC] Add MaterializationUnit::Interface parameter to ObjectLayer::add.

Also moves object interface building functions out of Mangling.h and in to the
new ObjectFileInterfaces.h header, and updates the llvm-jitlink tool to use
custom object interfaces rather than a custom link layer.

ObjectLayer::add overloads are added to match the old signatures (which
do not take a MaterializationUnit::Interface). These overloads use the
standard getObjectFileInterface function to build an interface.

Passing a MaterializationUnit::Interface explicitly makes it easier to alter
the effective interface of the object file being added, e.g. by changing symbol
visibility/linkage, or renaming symbols (in both cases the changes will need to
be mirrored by a JITLink pass at link time to update the LinkGraph to match the
explicit interface). Altering interfaces in this way can be useful when lazily
compiling (e.g. for renaming function bodies) or emulating linker options (e.g.
demoting all symbols to hidden visibility to emulate -load_hidden).

show more ...

[ORC] Add a MaterializationUnit::Interface struct.

MaterializationUnit::Interface holds the values that make up the interface
(for ORC's purposes) of a materialization unit: the symbol flags map and

[ORC] Add a MaterializationUnit::Interface struct.

MaterializationUnit::Interface holds the values that make up the interface
(for ORC's purposes) of a materialization unit: the symbol flags map and
initializer symbol.

Having a type for this will make functions that build materializer interfaces
more readable and maintainable.

show more ...

[ORC][ORC-RT] Reapply "Introduce ELF/*nix Platform and runtime..." with fixes.

This reapplies e256445bfff, which was reverted in 45ac5f54418 due to bot errors
(e.g. https://lab.llvm.org/buildbot/#/b

[ORC][ORC-RT] Reapply "Introduce ELF/*nix Platform and runtime..." with fixes.

This reapplies e256445bfff, which was reverted in 45ac5f54418 due to bot errors
(e.g. https://lab.llvm.org/buildbot/#/builders/112/builds/8599). The issue that
caused the bot failure was fixed in 2e6a4fce356.

show more ...

[ORC][JITLink][ELF] Treat STB_GNU_UNIQUE as Weak in the JIT.

This should fix the bot error in
https://lab.llvm.org/buildbot/#/builders/112/builds/8599
which forced reversion of the ELFNixPlatform in

[ORC][JITLink][ELF] Treat STB_GNU_UNIQUE as Weak in the JIT.

This should fix the bot error in
https://lab.llvm.org/buildbot/#/builders/112/builds/8599
which forced reversion of the ELFNixPlatform in 45ac5f54418.

This should allow us to re-enable the ELFNixPlatform in a follow-up patch.

show more ...

Revert "[ORC-RT][ORC] Introduce ELF/*nix Platform and runtime support."

This reverts commit e256445bfff12013c3c4ad97da4aa69d25b175b5.

This commit broke some of the bots (see e.g.
https://lab.llvm.o

Revert "[ORC-RT][ORC] Introduce ELF/*nix Platform and runtime support."

This reverts commit e256445bfff12013c3c4ad97da4aa69d25b175b5.

This commit broke some of the bots (see e.g.
https://lab.llvm.org/buildbot/#/builders/112/builds/8599). Reverting while I
investigate.

show more ...

[ORC-RT][ORC] Introduce ELF/*nix Platform and runtime support.

This change adds support to ORCv2 and the Orc runtime library for static
initializers, C++ static destructors, and exception handler re

[ORC-RT][ORC] Introduce ELF/*nix Platform and runtime support.

This change adds support to ORCv2 and the Orc runtime library for static
initializers, C++ static destructors, and exception handler registration for
ELF-based platforms, at present Linux and FreeBSD on x86_64. It is based on the
MachO platform and runtime support introduced in bb5f97e3ad1.

Patch by Peter Housel. Thanks very much Peter!

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D108081

show more ...

[ORC][ORC-RT] Add initial Objective-C and Swift support to MachOPlatform.

This allows ORC to execute code containing Objective-C and Swift classes and
methods (provided that the language runtime is

[ORC][ORC-RT] Add initial Objective-C and Swift support to MachOPlatform.

This allows ORC to execute code containing Objective-C and Swift classes and
methods (provided that the language runtime is loaded into the executor).

show more ...

[Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> getSymbolFlags().

This change enables getSymbolFlags() to return errors which benefit error reporting in clients.

Differential Revisi

[Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> getSymbolFlags().

This change enables getSymbolFlags() to return errors which benefit error reporting in clients.

Differential Revision: https://reviews.llvm.org/D77860

show more ...

[ORC] Introduce JITSymbolFlags::HasMaterializeSideEffectsOnly flag.

This flag can be used to mark a symbol as existing only for the purpose of
enabling materialization. Such a symbol can be looked u

[ORC] Introduce JITSymbolFlags::HasMaterializeSideEffectsOnly flag.

This flag can be used to mark a symbol as existing only for the purpose of
enabling materialization. Such a symbol can be looked up to trigger
materialization with the lookup returning only once materialization is
complete. Symbols with this flag will never resolve however (to avoid
permanently polluting the symbol table), and should only be looked up using
the SymbolLookupFlags::WeaklyReferencedSymbol flag. The primary use case for
this flag is initialization symbols.

show more ...

[JITLink][MachO] Re-apply b64afadf306, MachO linker-private support, with fixes.

Global symbols with linker-private prefixes should be resolvable across object
boundaries, but internal symbols with

[JITLink][MachO] Re-apply b64afadf306, MachO linker-private support, with fixes.

Global symbols with linker-private prefixes should be resolvable across object
boundaries, but internal symbols with linker-private prefixes should not.

show more ...

Revert "[JITLink][MachO] Treat linker private symbols as hidden rather than private."

This reverts commit b64afadf306f284a684ee656c6eefbd43c192c8d.

Reverting while I investigate bot failures.

[JITLink][MachO] Treat linker private symbols as hidden rather than private.

Linker-private symbols should be resolvable across object file boundaries.

[ORC] Skip ST_File symbols in MaterializationUnit interfaces / resolution.

ST_File symbols aren't relevant for linking purposes, but can end up shadowing
real symbols if they're not filtered.

No te

[ORC] Skip ST_File symbols in MaterializationUnit interfaces / resolution.

ST_File symbols aren't relevant for linking purposes, but can end up shadowing
real symbols if they're not filtered.

No test case yet: The ideal testcase for this would be an ELF llvm-jitlink test,
but llvm-jitlink support for ELF is still under development. We should add a
testcase for this once support lands in tree.

show more ...

[ORC] Make sure we add initializers to the SymbolFlags map for objects.

[ORC] Add generic initializer/deinitializer support.

Initializers and deinitializers are used to implement C++ static constructors
and destructors, runtime registration for some languages (e.g. with

[ORC] Add generic initializer/deinitializer support.

Initializers and deinitializers are used to implement C++ static constructors
and destructors, runtime registration for some languages (e.g. with the
Objective-C runtime for Objective-C/C++ code) and other tasks that would
typically be performed when a shared-object/dylib is loaded or unloaded by a
statically compiled program.

MCJIT and ORC have historically provided limited support for discovering and
running initializers/deinitializers by scanning the llvm.global_ctors and
llvm.global_dtors variables and recording the functions to be run. This approach
suffers from several drawbacks: (1) It only works for IR inputs, not for object
files (including cached JIT'd objects). (2) It only works for initializers
described by llvm.global_ctors and llvm.global_dtors, however not all
initializers are described in this way (Objective-C, for example, describes
initializers via specially named metadata sections). (3) To make the
initializer/deinitializer functions described by llvm.global_ctors and
llvm.global_dtors searchable they must be promoted to extern linkage, polluting
the JIT symbol table (extra care must be taken to ensure this promotion does
not result in symbol name clashes).

This patch introduces several interdependent changes to ORCv2 to support the
construction of new initialization schemes, and includes an implementation of a
backwards-compatible llvm.global_ctor/llvm.global_dtor scanning scheme, and a
MachO specific scheme that handles Objective-C runtime registration (if the
Objective-C runtime is available) enabling execution of LLVM IR compiled from
Objective-C and Swift.

The major changes included in this patch are:

(1) The MaterializationUnit and MaterializationResponsibility classes are
extended to describe an optional "initializer" symbol for the module (see the
getInitializerSymbol method on each class). The presence or absence of this
symbol indicates whether the module contains any initializers or
deinitializers. The initializer symbol otherwise behaves like any other:
searching for it triggers materialization.

(2) A new Platform interface is introduced in llvm/ExecutionEngine/Orc/Core.h
which provides the following callback interface:

- Error setupJITDylib(JITDylib &JD): Can be used to install standard symbols
in JITDylibs upon creation. E.g. __dso_handle.

- Error notifyAdding(JITDylib &JD, const MaterializationUnit &MU): Generally
used to record initializer symbols.

- Error notifyRemoving(JITDylib &JD, VModuleKey K): Used to notify a platform
that a module is being removed.

Platform implementations can use these callbacks to track outstanding
initializers and implement a platform-specific approach for executing them. For
example, the MachOPlatform installs a plugin in the JIT linker to scan for both
__mod_inits sections (for C++ static constructors) and ObjC metadata sections.
If discovered, these are processed in the usual platform order: Objective-C
registration is carried out first, then static initializers are executed,
ensuring that calls to Objective-C from static initializers will be safe.

This patch updates LLJIT to use the new scheme for initialization. Two
LLJIT::PlatformSupport classes are implemented: A GenericIR platform and a MachO
platform. The GenericIR platform implements a modified version of the previous
llvm.global-ctor scraping scheme to provide support for Windows and
Linux. LLJIT's MachO platform uses the MachOPlatform class to provide MachO
specific initialization as described above.

Reviewers: sgraenitz, dblaikie

Subscribers: mgorny, hiraditya, mgrang, ributzka, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74300

show more ...