Extend the logic for the WinSDK and UCRT handling to prefer a user
specified version of the VisualC++ tools and Windows SDK. This allows
us to now perform the regular search for the installation but select the
exact version of the SDK or VC++ tools to override the latest version.
Similar to the other flags controlling this behaviour, if the user
specifies a value, we will not perform validation on the input and will
attempt to prefer that, particularly in the case of VisualC++ tools
where no fallback occurs.
Reviewed by: hans
Differential Revision: https://reviews.llvm.org/D145517
Testing the COFFPlatform on MSVC, a name shadowing issue surfaced where `LoadDynLibrary` inside the constructor was actually using the moved-from function argument. This patch simply renames the argument to avoid that shadowing.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D145710
These values are moved into the base class constructors, so the `const` doesn't make any sense. Turns out, I accidentally introduced it myself with 2ed91da0f1f3 and since than it spread by copy/paste.
The existing Create method took a path to the ORC runtime and created a
StaticLibraryDefinitionGenerator for it. The new overload takes a
std::unique_ptr<DefinitionGenerator> directly instead. This provides more
flexibility when constructing MachOPlatforms. E.g. The runtime archive can be
embedded in a special section in the ORC controller executable or library,
rather than being on-disk.
This is the ELFNixPlatform equivalent of the MachOPlatform change in
be2fc577c38.
The existing Create method took a path to the ORC runtime and created a
StaticLibraryDefinitionGenerator for it. The new overload takes a
std::unique_ptr<DefinitionGenerator> directly instead. This provides more
flexibility when constructing MachOPlatforms. E.g. The runtime archive can be
embedded in a special section in the ORC controller executable or library,
rather than being on-disk.
Renames the existing allocateString method to allocateContent and adds a pair of
allocateCString methods.
The previous allocateString method did not include a null-terminator. It behaved
the same as allocateContent except with a Twine input, rather than an
ArrayRef<char>. Renaming allocateString to allocateBuffer (overloading the
existing method) makes this clearer.
The new allocateCString methods allocate the given content plus a
null-terminator character, and return a buffer covering both the string and
null-terminator. This makes them suitable for creating c-string content for
jitlink::Blocks.
Existing users of the old allocateString method have been updated to use the
new allocateContent overload.
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
The classification of TLS symbols in ELF was changed from ST_Data to
ST_Other in the following commit:
018a484cd26d72fb4c9e7fd75e5f5bc7838dfc73
RuntimeDyldELF::processRelocationRef() needs to be updated to also
handle ST_Other symbols so that it handles TLS relocations correctly.
The current tests did not fail because we have a shortcut for global
symbols that are already defined.
Differential Revision: https://reviews.llvm.org/D143568
According to the IR verifier, "Declaration[s] may not be in a Comdat!"
This is a re-commit of 76b3f0b4d5a0b8c54147c4c73a30892bbca76467 and
87d7838202267a011639fcbf97263556ccf091dc with updates to the test:
* Force emission of the extra-module, to trigger the bug after D138264,
by providing a second symbol @g, and making the comdat nodeduplicate.
(Technically only one is needed, but two should be safer.)
* Name the comdat $f to avoid failure on Windows:
LLVM ERROR: Associative COMDAT symbol 'c' does not exist.
* Mark the test as UNSUPPORTED on macOS, MachO doesn't support COMDATs.
Differential Revision: https://reviews.llvm.org/D142443
According to the IR verifier, "Declaration[s] may not be in a Comdat!"
This is a re-commit of 76b3f0b4d5a0b8c54147c4c73a30892bbca76467 with
updates to the test:
* Force emission of the extra-module, to trigger the bug after D138264,
by providing a second symbol @g, and making the comdat nodeduplicate.
(Technically only one is needed, but two should be safer.)
* Name the comdat $f to avoid failure on Windows:
LLVM ERROR: Associative COMDAT symbol 'c' does not exist.
Differential Revision: https://reviews.llvm.org/D142443
Failure on Windows:
LLVM ERROR: Associative COMDAT symbol 'c' does not exist.
This reverts commit 76b3f0b4d5a0b8c54147c4c73a30892bbca76467 while
I investigate the problem and a solution that still triggers the
original problem.
If an error occurs during the post-allocation phase (JITLinkerBase::linkPhase2)
then we need to call JITLinkMemoryManager::InFlightAlloc::abandon so that the
allocation has a chance to clean up. This was already handled for later phases,
but we were skipping the abandon step when we bailed out of phase 2.
Adds a getJITSymbolFlagsForSymbol function that returns the JITSymbolFlags
for a given jitlink::Symbol, and replaces severalredundant copies of that
mapping with calls to the new function. This fixes a bug in
LinkGraphMaterializationUnit::scanLinkGraph where we were failing to set the
JITSymbolFlags::Weak flag for weak symbols, and a bug in
ObjectLinkingLayer::claimOrExternalizeWeakAndCommonSymbols where we were
failing to set the JITSymbolFlags::Callable flag for callable symbols.
The loop body may add and remove entries in the symbol table so we can't hold
iterators to the entries. This commit updates the method to use the newly added
NonOwningSymbolStringPtr type as keys for removal instead.
Side note: This bug has been present since the introduction of the
defineMaterializing method, but the method is called rarely and DenseMap
resizes are also rare so we didn't see any fallout until a large program was
thrown at it. There's no testcase as I haven't been able to reproduce the
failure with smaller testcases.
This commit adds support for PLT based relocations. Specifically -
1. It adds logic to create a `PLTTableManager` in the `buildTables_ELF_i386`
function, which is called as part of the post-prune JITLink passes. The `PLTTableManager`
handles creating pointer jump stubs and related GOT entries for position independent
code.
2. It also adds a pre-fixup pass to optimize away PLT based calls in position independent
code, when possible.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D142846
Index 0 is reserved for anonymous symbols, which can't have the N_EXT bit
set (since N_EXT means non-local scope, and non-local scope requires a name).
This patch adds resolver, indirection and trampoline stubs for
loongarch64, allowing lazy compilation to work.
It assumes hard float feature exists.
Depends on D141036
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D141102
In LLVM the MachOPlatform class is modified to identify unwind info sections
and the address ranges of the functions these sections cover. These address
ranges are then communicated to the ORC runtime by attaching them to the
register-object-platform-sections allocation action.
In the ORC runtime the unwind-info section addresses are recorded and used to
support lookup of unwind info via the new `findDynamicUnwindSections` function.
At bootstrap time the ORC runtime checks for the presence of new
unwind-info-lookup-registration functions in libunwind (see
https://reviews.llvm.org/D142176), and if available uses them to register the
`findDynamicUnwindSections` function with libunwind to enable callback-based
lookup. If the new unwind-info-lookup-registration functions are not available
then the ORC runtime falls back to using the existing libunwind registration
APIs.
The callback-based scheme is intended to address three shortcomings in the
current registration scheme for JIT'd unwind info on Darwin: (1) Lack of
compact-unwind support, (2) inability to describe the subarchitecture of JIT'd
frames, and (3) lack of efficient address-based lookup data structures in
libunwind.
For more details see the proposed libunwind changes in
https://reviews.llvm.org/D142176.
This implementation supports basic relocation types and adds EHFrame,
Got/Plt handling passes.
This patch also enables JIT support for LoongArch64.
With this patch, I successfully run hello.ll and simple_throw.ll
(which is generated from test-suite/SingleSource/Regression/C++/EH/simple_throw.cpp)
using the `lli` command with options `--jit-kind=orc --jit-linker=jitlink`.
Note: `hasJIT` property of LoongArch32 remains false as there is no
validation environment.
New changes: Since LoongArch does not support RuntimeDyld, JITLink is set
by default. Add a null-terminator to eh-frame sections. This should fix
the test failure on LoongArch bot.
(https://lab.llvm.org/staging/#/builders/236/builds/896)
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D141036
This implementation supports basic relocation types and adds EHFrame,
Got/Plt handling passes.
This patch also enables JIT support for LoongArch64.
With this patch, I successfully run hello.ll and simple_throw.ll
(which is generated from test-suite/SingleSource/Regression/C++/EH/simple_throw.cpp)
using the `lli` command with options `--jit-kind=orc --jit-linker=jitlink`.
Note: `hasJIT` property of LoongArch32 remains false as there is no
validation environment.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D141036
Similar to how `makeArrayRef` is deprecated in favor of deduction guides, do the
same for `makeMutableArrayRef`.
Once all of the places in-tree are using the deduction guides for
`MutableArrayRef`, we can mark `makeMutableArrayRef` as deprecated.
Differential Revision: https://reviews.llvm.org/D141814
The i386/ELF JITLink backend was not correctly handling the GOTPC relocation
by skipping the in-built addend, which was manifesting itself in the form of
a segmentation fault in the `LF_external_to_absolute_conversion.s` test. This
CR has fixed that issue.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D141746
This patch modifies the MachOPlatform bootstrap process to record allocation
actions for ORC runtime platform support code in a "deferred actions" vector
rather than attaching it to the corresponding LinkGraphs up-front. The deferred
allocation-actions are run after all the platform support code has been loaded
by attaching them to a separate "bootstrap-complete" graph.
This change should allow the mach-o platform support code in the ORC runtime to
use advanced mach-o platform features (e.g. static inits, TLVs), provided that
the support code does not use these features at runtime before the bootstrap
process completes, or after the shutdown process starts. This is a nice
improvement in and of itself but is motivated by specific future plans: we
want to start recording unwind info in the mach-o platform state object*, and
the recording functions will have their own frame info that needs registering.
The deferred allocation-actions scheme allows for this.
* The plan is to add a new unwind-info-lookup path to libunwind to allow it to
call back to the ORC runtime to find unwind sections. This will simplify the
implementation of support for JIT'd compact-unwind info.
Use an private struct, RuntimeFunction, to to keep the name and address of each
registration function together, and rename the member variables with their purpose
rather than the full name of the function in the runtime.
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
These are the compressed equivalents of the relocations R_RISCV_BRANCH
and R_RISCV_JAL with slightly more complex immediate handling.
Differential Revision: https://reviews.llvm.org/D140827
Name the variables based on which part of the immediate value is
extracted, as it was already done for R_RISCV_JAL. This makes it
much easier to compare the logic with the spec.
Differential Revision: https://reviews.llvm.org/D140820
There were basically four different orderings: one defined by the
relocations, one by the enum definition of EdgeKind_riscv, one for
mapping the enum values to their names, and one when mapping the
relocations to edge kinds and finally processing them. Chose the
ordering defined by the relocations in the riscv-elf-psabi-doc as
the canonical one.
Differential Revision: https://reviews.llvm.org/D140802
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175.
This reverts commit 06b90e2e9c991e211fecc97948e533320a825470.
This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
