Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and
__jit_debug_register_code so there exported even if LLVM is not built as
a shared library.
This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows #109483.
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
`LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES` is not completely
compatible with `export_executable_symbols` as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
`llvm_add_exectuable` so the link flag can be determined directly
without calling `export_executable_symbols_*` later.
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.
Integrate in-memory debug-info dumps into the `--orc-lazy-debug`
command-line option instead of exposing built-in functions to be called
from JITed code. This reduces overall amount of code (removing
`ExecutionUtils.cpp`) and seems cleaner anyway.
All existing items of `OrcDumpKind` work on IR level and run in the
IR-transform step of the JIT. The newly added `DumpDebugDescriptor` and
`DumpDebugObjects` must run after debug-registration and thus are
deferred to the Object-transform step of the JIT. This separation is the
major side-effect of the patch.
The original commit 263efb044add93b9 was reverted in #79055, because
the gcc 7.5 bot had found a missing std::move().
Reverts llvm/llvm-project#76822
This fails to build with gcc 7.5:
```
llvm/tools/lli/lli.cpp:1087:16: error: could not convert ‘Obj’ from ‘std::unique_ptr<llvm::MemoryBuffer>’ to ‘llvm::Expected<std::unique_ptr<llvm::MemoryBuffer> >’
return Obj;
^~~
```
Integrate in-memory debug-info dumps into the `--orc-lazy-debug`
command-line option instead of exposing built-in functions to be called
from JITed code. This reduces overall amount of code (removing
`ExecutionUtils.cpp`) and seems cleaner anyway.
All existing items of `OrcDumpKind` work on IR level and run in the
IR-transform step of the JIT. The newly added `DumpDebugDescriptor` and
`DumpDebugObjects` must run after debug-registration and thus are
deferred to the Object-transform step of the JIT. This separation is the
major side-effect of the patch.
Forcing the JITLinker to the default configuration shouldn't affect the
configuration of the JIT. Since it's implemented by setting the
ObjectLinkingLayerCreator, it did have side-effects though. In
particular, we skipped the Code- and RelocationModel setting in
`LLJITBuilderState::prepareForConstruction()`.
This migrates the dylib manager lookup and related APIs to replace
ExecutorAddress with ExecutorSymbolDef so that in the future we can
model JITSymbolFlags for these symbols. The current change should be NFC
as we are only setting the Exported symbol flag.
https://github.com/llvm/llvm-project/pull/76236 introduced the forth
copy and it was time to deduplicate. This patch brings it back to 2,
one in OrcTargetProcess and one in legacy ExecutionEngine.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This re-applies db51e572893, which was reverted in 05b1a2cb3e6 due to bot
failures. The DebuggerSupportPlugin now depends on DWARF, so it has been moved
to the new OrcDebugging library (as has the enableDebuggerSupport API).
This re-applies e1a5bb59b91, which was reverted in e5f169f91a8 due to LSan
failures on some bots (see https://github.com/llvm/llvm-project/issues/67586).
The LSan failures were not caused by this patch (just exposed by it), so LSan
was disabled for the failing test in 47625fea5e3. This should be safe to
re-land now.
This change means that debugger support only needs to be linked in if it's
used. The code size of debugger support is expected to increase as we improve
it (e.g. pulling in DWARF parsing), so making it an optional extra is useful
for controlling final binary sizes.
This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.
This matches other nearby enums.
For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::
The trick we use (since cbc2a0623a39461b56bd9eeb308ca535f03793f8)
for exporting the __chkstk function (with various per-arch names)
that is defined in a different object file, relies on the function
already being linked in (by some function referencing it).
This function does end up referenced if there's a function that
allocates more than 4 KB on the stack. In most cases, it's referenced
somewhere, but in the case of builds with LLVM_LINK_LLVM_DYLIB
enabled (so most of the code resides in a separate libLLVM-<ver>.dll)
the only code in lli.exe is the lli tool specific code and the
mingw-w64 crt startup code. In the case of GCC based MinGW i386
builds with LLVM_LINK_LLVM_DYLIB, nothing else references it though.
Manually add a reference to the function to make sure it is linked
in (from libgcc or compiler-rt builtins) so that it can be exported.
This fixes one build issue encountered in
https://github.com/msys2/MINGW-packages/pull/18002.
Differential Revision: https://reviews.llvm.org/D159085
Without this function lli will error out on MinGW with a missing symbol error
for __main.
Cygwin and MinGW insert calls from the main function to the runtime function
__main. The __main function is responsible for setting up main's environment
(e.g. running static constructors), however this is not needed when running
under lli: the executor process will have run non-JIT ctors, and ORC will take
care of running JIT'd ctors. To avoid a missing symbol error we just implement
__main as a no-op.
Clients can now call LLJITBuilder::setEnableDebuggerSupport to enable
registration of debug info via the GDB-JIT registration protocol for JIT'd
code.
Calling LLJITBuilder::setEnableDebuggerSupport(true) will cause LLJITBuilder to
add either a DebugObjectManagerPlugin (if the object format on the triple is
ELF), or a GDBJITDebugInfoRegistrationPlugin (if the object format on the
triple is MachO). At present there is no support for debugging when using COFF.
This debugger registration support will only work when JITLink is used as the
underlying JIT linker.
This patch only addresses registration of JIT'd code by the JIT. To debug JIT'd
code you may also need to enable JIT'd code debugging in your debugger. E.g.
when debugging MachO JIT'd code under LLDB you will currently need to run
(lldb) set set plugin.jit-loader.gdb.enable on
to tell LLDB to listen for JIT'd code registration.
This reapplies 371cb1af61d, which was reverted in 0b2240eda01 due to bot
failures.
The clang-repl test failure is fixed by dropping the process symbols definition
generator that was manually attached to the main JITDylib, since LLJIT now
exposes process symbols by default. (The bug was triggered when JIT'd code used
the process atexit provided by the generator, rather than the JIT atexit which
has been moved into the platform JITDylib).
Any LLJIT clients that see crashes in static destructors should likewise remove
any process symbol generators attached to their main JITDylib.
This commit includes several related ergonomic improvements to LLJIT.
(1) Adds a default JITDylibSearchOrder to be appended to the initial link order
of JITDylibs created via LLJIT::createJITDylib (dropping any duplicate entries).
This was introduced to support automatic reflection of process symbols (see
(2) below), but has been made visible to clients as it's generically useful,
e.g. if clients have some extra set of libraries that they want to be visible
to JIT'd code by default.
The default JITDylibSearchOrder is only appended to the link order of JITDylibs
created via LLJIT::createJITDylib, and will not be apply to JITDylibs created by
directly calling the underlying ExecutionSession -- in that case clients can set
up the link order manually.
(2) Makes process symbols visible to JIT'd code by default via the new "Process"
JITDylib, which is added to the default link order.
LLJIT clients usually want symbols in the executor process to be accessible to
JIT'd code. Until now clients have been left to set this up themselves by adding
a DynamicLibrarySearchGenerator to the Main JITDylib. This patch adds a new
process symbols JITDylib that will be created by default (with an
EPCDynamicLibrarySearchGenerator attached) and added to the default link order,
making process symbols available to JIT'd code.
Clients who do not want process symbols to be visible to JIT'd code by default
can call setLinkProcessSymbolsByDefault(false) on their LLJITBuilder to disable
this:
LLJITBuilder()
...
.setLinkProcessSymbolsByDefault(false)
...
.create();
Clients can also call setProcessSymbolsJITDylibSetup to take over responsibility
for configuring the process symbols JITDylib (the callback that the client
supplies will be called on the bare process symbols JITDylib immediately after
it is created).
If setLinkProcessSymbolsByDefault(false) is called and no JITDylib setup
callback has been set then the process symbols JITDylib will not be created and
LLJIT::getProcessSymbolsJITDylib will return null.
(3) Adds an ExecutorNativePlatform utility that makes it easier to enable
native platform features.
Some object format features (e.g. native static initializers and thread locals)
require runtime support in the executing process. Support for these features in
ORC is implemented cooperatively between the ORC runtime and the LLVM Platform
subclasses (COFFPlatform, ELFNixPlatform, and MachOPlatform).
ExecutorNativePlatfrom simplifies the process of loading the ORC runtime and
creating the appropriate platform class for the executor process.
ExecutorNativePlatform takes a path to the ORC runtime (or a MemoryBuffer
containing the runtime) and other required runtimes for the executor platform
(e.g. MSVC on Windows) and then configures LLJIT with an appropriate platform
class based on the executor's target triple:
LLJITBuilder()
.setPlatformSetUp(ExecutorNativePlatform("/path/to/orc-runtime.a"));
(The ORC runtime is built as part of compiler-rt, and the exact name of the
archive is platform dependent).
The ORC runtime and platform symbols will be added to a new "Platform" JITDylib,
which will be added to the *front* of the default link order (so JIT'd code will
prefer symbol definitions in the platform/runtime to definitions in the executor
process).
ExecutorNativePlatform assumes that the Process JITDylib is available, as
the ORC runtime may depend on symbols provided by the executor process.
Differential Revision: https://reviews.llvm.org/D144276
Configure the plugin to automatically call the debugger rendezvous breakpoint `__jit_debug_register_code()` for every translation unit (enabled) or never at all (disabled). Default API and behavior remain unchanged.
If AutoRegisterCode is turned off, it's the client's own responsibility to call the rendezvous breakpoint function at an appropriate time.
Depending on the complexity of the debugger's rendezvous breakpoint implementation, this can provide significant performance improvements in cases where many debug objects are added in sequence.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D147310
ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for
JITTargetAddress. ExecutorSymbolDef is introduced in this patch as a
replacement for JITEvaluatedSymbol: ExecutorSymbolDef is an (ExecutorAddr,
JITSymbolFlags) pair, where JITEvaluatedSymbol was a (JITTargetAddress,
JITSymbolFlags) pair.
A number of APIs had already migrated from JITTargetAddress to ExecutorAddr,
but many of ORC's internals were still using the older type. This patch aims
to address that.
Some public APIs are affected as well. If you need to migrate your APIs you can
use the following operations:
* ExecutorAddr::toPtr replaces jitTargetAddressToPointer and
jitTargetAddressToFunction.
* ExecutorAddr::fromPtr replace pointerToJITTargetAddress.
* ExecutorAddr(JITTargetAddress) creates an ExecutorAddr value from a
JITTargetAddress.
* ExecutorAddr::getValue() creates a JITTargetAddress value from an
ExecutorAddr.
JITTargetAddress and JITEvaluatedSymbol will remain in JITSymbol.h for now, but
the aim will be to eventually deprecate and remove these types (probably when
MCJIT and RuntimeDyld are deprecated).
LLJIT::loadPlatformDynamicLibrary loads a dynamic library at a given path
(interpreted in the executor process -- the process containing the JIT'd code),
and returns a JITDylib (whose name is the given path) that reflects the symbols
in that library. LLJIT clients wishing to make the given symbols visible to
their JIT'd code can add this JITDylib to the link order of their JITDylib(s)
using JITDylib::addToLinkOrder.
The LLJIT::linkStaticLibraryInto overloads load a static library (or universal
binary) at a given path (interpreted in the controller process -- the process
containing the LLJIT instance) and adds its symbols to the given JITDylib.
The lli tool is updated to use LLJIT::linkStaticLibraryInto to implement the
extra-archive option.
LLJIT::loadPlatformDynamicLibrary is not tested in this patch as we don't have
a good way to produce dylibs in LLVM's regression test suite.
This reverts commit bdf5f9c3228d6ed1d7c6f87b3828a7d573b34c03, which was a work
in progress for https://reviews.llvm.org/D144276 and accidentally committed
early.
Simplifies the process of building an LLJIT instance that supports the native
platform features (initializers, TLV, etc.).
SetUpExecutorNativePlatform can be passed to LLJITBuilder::setPlatformSetUp
method. It takes a reference to the ORC runtime (as a path or an in-memory
archive) and automatically sets the platform for LLJIT's ExecutionSession based
on the executor process's triple.
Differential Revision: https://reviews.llvm.org/D144276
Adds perf event listeners when RTDyldObjectLinkingLayer is used in -jit-kind=orc
mode.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D126214
When lli is run with -jit-kind=mcjit and without remote JITing there is no need
to create an ExecutorProcessControl object.
This is nice cleanup, but as a bonus should silence the leak reports that we're
seeing in https://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan/9105/.
(Though as a side note I believe those reports are spurious. They are being
tracked by rdar://104825696).
Add free functions llvm::CodeGenOpt::{getLevel,getID,parseLevel} to
provide common implementations for functionality that has been
duplicated in many places across the codebase.
Differential Revision: https://reviews.llvm.org/D141968
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This fixes check-llvm.
