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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
