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 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.
The in-process symbol generator resolves symbols available in the process and
all dlopened libraries. However, upon unresolved symbol, we trigger our lazy
loading function creator callbacks which load the relevant library. Then we
need another in-process symbol generator to catch the newly created symbol so
that the JIT is happy.
This solution is suboptimal and in the comments is provided a cleaner
implementation, however, this implementation loads libraries for weak symbols
that the JIT could generate. This needs to be further investigated.
This patch also inverts the parameter from ExcludeHostSymbols to
IncludeHostSymbols to improve readability.
As written in one of the FIXMEs this is a temporary solution which allows us to
go further with the llvm-13 upgrade. We can rework the getAddress* functionality
to reuse more the ORCV2 infrastructure and more importantly to use that
infrastructure in the recommended way.
When removing code, we need to recover Clang's CodeGen and this happens by
iterating over the clang::Decls and the llvm::Module for a given Transaction in
the TransactionUnloader.
The problem is that now OrcV2 takes the ownership of the llvm::Module from the
Transaction for itself and then it can notify us when the module was compiled on
demand. Unfortuantely, there is no good way to guarantee that the same module
will be attached to the same transaction. This approach allows the
TransactionUnloader::unloadModule logic to recover CodeGen.
In a longer term, when we switch to partial translation units from clang-repl
we might be able to recover CodeGen without needing to know details about the
generated llvm::Module.
When we compile incremental inputs we store each input in a separate
llvm::Module. In order to preserve the semantics, we make all symbols from
each module with external linkage, that is, accessible from other modules.
This model works well for almost all symbols, except for the clang-generated
ones which have the same name. For example clang stores strings in variables
`.strN` which may clash accross modules. Luckily, these strings are used within
a single module and thus we can avoid the JIT error by keeping them with their
non-external linkage.
