IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This makes all functions end up in the same text section, which is
important for TCling on macOS to catch exceptions from constructors:
Stack unwinding requires information about program addresses to find
out which objects to destroy and what code should be called to handle
the exception. These addresses are relocated against a single __text
section when loading the produced MachO binary, which breaks if the
call sites of global constructors end up in a separate init section.
Fixes ROOT-10703 and ROOT-10962
(cherry picked from commit 028fcca0fa76111877751df876cf13968be602f9)
The function EnforceInitOrder() was using ImplicitlyDefineFunction()
as a shortcut to define a function returning an int. Future upgrades
of LLVM will add an assert in that function because it is not allowed
to be used when compiling C++, which Cling obviously does.
m_JIT.getSymbolAddress() invokes the symbol materializers, which compile (which
is sort of okay) but also try autoloading (which totally is not okay).
Instead, implement a function to search existing JIT symbols.
This can be accelerated by looking up the whole set of symbols, instead of doing it
symbol by symbol. I leave that refactoring for later...
With the upgrade to llvm-13, the JIT lost the ability to re-use existing weak
symbols that the JIT had already emitted, instead only looking at dlsym. This
causes a significant increase in JITted symbols, and thus a significant slow-down
of cling / its JIT.
This restores the old behavior, with an identical set of symbols that jet jitted.
With the upgrade, BackendPasses was modifying a TargetMachine that was
not used by SimpleCompiler.
Change that by
- using a SimpleCompiler that uses IncrementalJIT::TM;
- moving the TM creation to IncrementalJIT, and giving access to it
This reduces the runtime of https://github.com/root-project/root/issues/11927
to
- before llvm upgrade: 2.69s
- llvm13, without this commit: ???
- llvm13, with this commit: 2.89s
i.e, a slow-down of 7% (that is likely caused by the different emission
mechanism of Orc-v2; to be confirmed...)
This feature, originally added in commit 22b1606f, was reverted to
make the LLVM upgrade to version 13 easier. This commit adds back
all functionality as it was just before the LLVM upgrade.
LLVM currently has an issue that a completely empty source file is
stored as a nullptr, but DIFile::getSource() does not correctly deal
with this situation. A crash can be observed if just attempting to
launch root.exe with EXTRA_CLING_ARGS="-gdwarf-5 -gembed-source".
See https://reviews.llvm.org/D137152 and https://reviews.llvm.org/D138658
for discussions with upstream.
* Fix compilation with VS 2022 v17.4
This fixes the issue #10875 _HAS_CONDITIONAL_EXPLICIT=0 won't work with VS 2022 17.4
* In fact with LLVM 13 this workaround is not needed anymore
When creating orec-Symbols for dylib symbols, reloading the
dylib might mean a change in symbol (address). So unloading a
dylib means we need to unload the orc-Symbol.
This is implemented through resource-tracking the symbols as
provided by DynamicLibrarySearchGenerator. Actually, as
DynamicLibrarySearchGenerator does not support resource tracking,
it is implemented in a near-copy of DynamicLibrarySearchGenerator,
RTDynamicLibrarySearchGenerator, which uses the transaction of the
most recent module for the ResourceTracker.
This is still required for proper exception handling support. See
commits 3f74182697 and a7b0b3e647 by Philippe for details on the
problem and the original code, which I was able to significantly
simplify with the new JIT infrastructure.
For the moment, this disables JITLink even on platforms that had it
active by default (notably macOS). This will be reintroduced at a
later point, which will require a memory manager implementation for
the JITLink interface.
Previously, one needed to pass linker-mangled names, which exposes details that
clients of IncrementalExecutor should not have to deal with. Instead, use the IR
name and do the linker-mangling in IncrementalJIT::addOrReplaceDefinition().
This fixes the lack of static destruction on macOS, visible e.g. in the test
failure of roottest/cling/staticinit/ROOT-7775.
The relocation needs to allow for long offsets, as for the JIT, __dso_handle
might be outside the shared library. Fixes
```
cling JIT session error: In graph cling-module-10-jitted-objectbuffer, section __TEXT,__StaticInit: relocation target "___dso_handle" at address 0x7fe1ee5052e0 is out of range of Delta32 fixup at 0x108c410bd (___cxx_global_var_initcling_module_10_, 0x108c41090 + 0x2d)
[runStaticInitializersOnce]: Failed to materialize symbols: { (main, { $.cling-module-10.__inits.0, __ZN12IncidentTypeL2m1E, __ZN6MarkerD2Ev, __ZN6MarkerD1Ev, ___cxx_global_var_initcling_module_10_.1, __GLOBAL__sub_I_cling_module_10, __ZN6MarkerC2EPKc, ___cxx_global_var_initcling_module_10_.3, __ZN12IncidentTypeL2m3E, __ZN6MarkerC1EPKc, __ZN12IncidentTypeL2m2E, ____orc_init_func.cling-module-10, ___cxx_global_var_initcling_module_10_ }) }
```
as seen no RISC-V and macOS, i.e. with the JITLinker.
OrcV2 uses specific DyLibs to resolve symbols from, we need a dedicated
resolver for libCling because its symbols cannot be found from the
process.
Remove now unused "ExposeHiddenSharedLibrarySymbols".
Since cling was ported to LLVM 13, it is required that the
`__cuda_register_globals` function and the `__cuda_fatbin_wrapper` and
`__cuda_gpubin_handle` variables are unique when defining a CUDA kernel.
Otherwise, the JIT is lazy and reuses the compiled version of
`__cuda_register_globals`, `__cuda_fatbin_wrapper` and `__cuda_gpubin_handle`
from the first CUDA kernel definition for all subsequent CUDA kernel
definitions, which in practice means that the PTX code from the first kernel is
re-registered each time.
Increase the default CUDA SM level to 35 because SM 20 is deprecated or
removed in the current CUDA SDK versions.
Replace the existing LazyFunctionCreator interface by a function
to add DefinitionGenerators to be passed via the chain Interpreter
-> IncrementalExecutor -> IncrementalJIT.
Implement a DefinitionGenerator in TCling(Callbacks) to define
MaterializationUnits for autoloading symbols. This also allows to
remove the double DynamicLibrarySearchGenerator now that the created
AutoloadLibraryMUs inject the addresses into the JIT after loading
the required library.
IncrementalExecutor has its own, showing what is requesting the
symbols, which is more useful than the diagnostic of Orc. OTOH
Orc might emit more errors than just missing symbols, and if
there are multiple missing symbols, IncrementalExecutor only
shows the first.
So enable `Verbose` also for IncrementalJIT, showing the original
missing symbols as diagnosed by Orc.
This fixes roottest_cling_other_checkMissingSymbolExitCode which
fails due to the extra diagnostic error line.
Introduce a backend pass that changes the linkage of external symbols
starting with "_ZT" (ie. typeinfo names, typeinfos, and vtables) to
weak symbols. This avoids duplicate symbol errors with the new JIT
linker.
FIXME: This is a hack, we should teach the frontend to emit these
only once, or mark all duplicates as available_externally (if that
improves performance due to optimizations).
It is (again) necessary to call DefineUsedVTables() to enable (at
least) the emission of implicitly defined destructors overriding
the virtual destructor in a base class, see the added test.
OSX (due to legacy to disambigate between asm and C symbols) implements an extra
linker-level mangling which adds another `_` in the name. However, that is only
in the on-disk representation and needs to be dropped upon calling dlsym.
OrcV2 gives us a handle to the symbol with starts with `__` allowing us to
invert the logic of the symbol search where we drop the `__` for dlsym.
