This stub type loads an absolute address directly into the PC register.
It's the simplest and most compatible way to implement a branch
indirection across the entire address space (and probably the slowest as
well). It's the ideal fallback for all targets for which we did not
(yet) implement a more performant solution.
`R_ARM_PREL31` is a 31-bits relative data relocation where the
most-significant bit is preserved. It's used primarily in `.ARM.exidx`
sections, which we skipped processing until now, because we didn't
support the relocation type. This was implemented in RuntimeDyld with
https://reviews.llvm.org/D25069 and I implemented it in a similar way in
JITLink in order to reach feature parity.
We want to emit stubs that match the instruction set state of the
relocation site. This is important for branches that have no built-in
switch for the instruction set state. It's the case for Jump24
relocations. Relocations on instructions that support switching on
the fly will be rewritten in a relaxation step in the future. This
affects Call relocations on `BL`/`BLX` instructions.
In this patch, the StubManager gains a second stub symbol slot for each
target and selects which one to use based on the relocation type. For
testing, we select the appropriate slot with a stub-kind filter, i.e.
`arm` or `thumb`. With that we can implement Armv7 stubs and test
that we can have both kinds of stubs for a single external symbol.
Specifying relocation fixup constants with name and type facilitates
readability and compile-time checks. The `FixupInfo<EdgeKind>` facade
organizes the information into entries per relocation type and provides
uniform access across Arm and Thumb relocations. Since it uses template
specializations, it doesn't limit potential entries. We cannot access
the entries dynamically though, because `EdgeKind` must be given as a
compile-time constant.
With this patch we populate a static lookup table on-demand and use it
for dynamic access in opcode-checks.
Reading implicit addend from a relocation site doesn't require a complete
`LinkGraph` edge. The operation is independent from `TargetSymbol`,
but constructing an `Edge` instance required one. This patch fixes the
inconsistency and simplifies some setup code from the error unittests.
Furthermore this patch prepares for the `Arm`/`Thumb`/`Data` helper
functions to be turned into implementation details. Exposing them in the
API causes unfortunate inconsistencies that we don't want to error-check
all the time, e.g. passing `Thumb_Call` to `readAddendArm()`.
Support for ELF::R_ARM_THM_MOVW_PREL_NC and ELF::R_ARM_THM_MOVT_PREL
is added. Move instructions with PC-relative immediates can be handled
in Thumb mode with this addition.
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class. This patch replaces
{big,little,native} with llvm::endianness::{big,little,native}.
This patch completes the migration to llvm::endianness and
llvm::endianness::{big,little,native}. I'll post a separate patch to
remove the migration helpers in llvm/Support/Endian.h:
using endianness = llvm::endianness;
constexpr llvm::endianness big = llvm::endianness::big;
constexpr llvm::endianness little = llvm::endianness::little;
constexpr llvm::endianness native = llvm::endianness::native;
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.
We should eventually migrate llvm::support::endianness to std::endian
when C++20 is available for the codebase.
This patch prepares our codebase for that future by removing the
assumption that native is a unique value different from both big and
little. Note that in C++20, native is equal to either big or little
on typical machines, where the endianness is the same for all scalar
types.
Add support for static Arm relocations of R_ARM_MOVT_ABS and R_ARM_MOVW_ABS_NC
which are emitted by movt and movw instructions. The implementation contains
relocation fixup and its testing as well as its encode/decode functions for
reading and writing immediate values together with its unittests.
We don't have to set or clear the Thumb bit in relocation fixup values.
It's not part of the branch range and the respective encoding functions
like encodeImmBT4BlT1BlxT2() shift out the least significant bit anyway.
This was a leftover from the initial patch before we switched to store
Thumb state in target-flags with D146641.
- Added WritableArmRelocation and ArmRelocation Structs
- Encode/Decode funcs for B/BL A1 and BLX A2 encodings
- Add ARM helper functions, consistent with the existing Thumb helper functions
- Add Test for ELF::R_ARM_CALL
Reviewed By: sgraenitz
Differential Revision: https://reviews.llvm.org/D157533
This re-applies 4b17c81d5a5, "[jitlink/rtdydl][checker] Add TargetFlag
dependent disassembler switching support", which was reverted in
4871a9ca546 due to bot failures.
The patch has been updated to add missing plumbing for Subtarget Features and
a CPU string, which should fix the failing tests.
https://reviews.llvm.org/D158280
Some targets such as AArch32 make use of TargetFlags to indicate ISA mode. Depending
on the TargetFlag, MCDisassembler and similar target specific objects should be
reinitialized with the correct Target Triple. Backends with similar needs can
easily extend this implementation for their usecase.
The drivers llvm-rtdyld and llvm-jitlink have their SymbolInfo's extended to take
TargetFlag into account. RuntimeDyldChecker can now create necessary TargetInfo
to reinitialize MCDisassembler and MCInstPrinter. The required triple is obtained
from the new getTripleFromTargetFlag function by checking the TargetFlag.
In addition, breaking changes for RuntimeDyld COFF Thumb tests are fixed by making
the backend emit a TargetFlag.
Reviewed By: lhames, sgraenitz
Differential Revision: https://reviews.llvm.org/D158280
We create LinkGraph sections with NoAlloc lifetime now since f05ac803ffe76c7f4299a4e1288cc6bb8b098410
This means we do process debug info sections now with all their relocations. That's ok for the moment.
I don't think these are holding their weight and cause nasty to debug
compiler issues with some versions of MSVC as seen in
https://reviews.llvm.org/D144083#4220866
Just qualify the types with the full name.
This first version lays the foundations for AArch32 support in JITLink. ELFLinkGraphBuilder_aarch32 processes REL-type relocations and populates LinkGraphs from ELF object files for both big- and little-endian systems. The ArmCfg member controls subarchitecture-specific details throughout the linking process (i.e. it's passed to ELFJITLinker_aarch32).
Relocation types follow the ABI documentation's division into classes: Data (endian-sensitive), Arm (32-bit little-endian) and Thumb (2x 16-bit little-endian, "Thumb32" in the docs). The implementation of instruction encoding/decoding for relocation resolution is implemented symmetrically and is testable in isolation (see AArch32 category in JITLinkTests).
Callable Thumb functions are marked with a ThumbSymbol target-flag and stored in the LinkGraph with their real addresses. The thumb-bit is added back in when the owning JITDylib requests the address for such a symbol.
The StubsManager can generate (absolute) Thumb-state stubs for branch range extensions on v7+ targets. Proper GOT/PLT handling is not yet implemented.
This patch is based on the backend implementation in ez-clang and has just enough functionality to model the infrastructure and link a Thumb function `main()` that calls `printf()` to dump "Hello Arm!" on Armv7a. It was tested on Raspberry Pi with 32-bit Raspbian OS.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D144083
This first version lays the foundations for AArch32 support in JITLink. ELFLinkGraphBuilder_aarch32 processes REL-type relocations and populates LinkGraphs from ELF object files for both big- and little-endian systems. The ArmCfg member controls subarchitecture-specific details throughout the linking process (i.e. it's passed to ELFJITLinker_aarch32).
Relocation types follow the ABI documentation's division into classes: Data (endian-sensitive), Arm (32-bit little-endian) and Thumb (2x 16-bit little-endian, "Thumb32" in the docs). The implementation of instruction encoding/decoding for relocation resolution is implemented symmetrically and is testable in isolation (see AArch32 category in JITLinkTests).
Callable Thumb functions are marked with a ThumbSymbol target-flag and stored in the LinkGraph with their real addresses. The thumb-bit is added back in when the owning JITDylib requests the address for such a symbol.
The StubsManager can generate (absolute) Thumb-state stubs for branch range extensions on v7+ targets. Proper GOT/PLT handling is not yet implemented.
This patch is based on the backend implementation in ez-clang and has just enough functionality to model the infrastructure and link a Thumb function `main()` that calls `printf()` to dump "Hello Arm!" on Armv7a. It was tested on Raspberry Pi with 32-bit Raspbian OS.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D144083
