Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows pointer comparisons (rather
than string comparisons) between Symbol names. This should improve the
performance and readability of code that bridges between JITLink and ORC (e.g.
ObjectLinkingLayer and ObjectLinkingLayer::Plugins).
To enable use of SymbolStringPtr a std::shared_ptr<SymbolStringPool> is added to
LinkGraph and threaded through to its construction sites in LLVM and Bolt. All
LinkGraphs that are to have symbol names compared by pointer equality must point
to the same SymbolStringPool instance, which in ORC sessions should be the pool
attached to the ExecutionSession.
---------
Co-authored-by: Lang Hames <lhames@gmail.com>
As noted in issues #68594 and #73935, `JITLink/RISCV/ELF_ehframe.s`
fails with libstdc++'s expensive checks because `getRISCVPCRelHi20`
calls `std::equal_range` on the edges which may not be ordered by their
offset. Instead let `ELFJITLinker_riscv` build a hashmap of all edges
with type `R_RISCV_PCREL_HI20` that can be looked up in constant time.
Closes#73935
This code appears to be a hack to set the features to include compressed
instructions if the ELF EFLAGS flags bit is present, but the ELF
attribute for the ISA string is no present or not accurate.
We can't remove the hack because llvm-mc doesn't create ELF attributes
by default so a lot of tests fail to disassembler properly. Using clang
as the assembler does set the attributes.
This patch changes the hack to only set Zca since that is the minimum
implied by the flag. Setting anything else potentially conflicts with
the ISA string containing Zcmp or Zcmt.
JITLink also needs to be updated to recognize Zca in addition to C.
Finalization of relaxation calls `finalizeBlockRelax` for every block in
the graph. This function, however, would iterate over //all// blocks in
the graph to remove `AlignRelaxable` edges. Since pointers to those
edges would still be stored in `RelaxEdges`, this caused a
use-after-free for graphs with multiple blocks.
This patch fixes this by only iterating over the edges of the current
block in `finalizeBlockRelax`.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D154844
`JITLinkContext` is notified (using `notifyResolved`) of the final
symbol addresses after allocating memory and running the post-allocation
passes. However, linker relaxation, which can cause symbol addresses to
change, was run during the pre-fixup passes. This causes users of
JITLink (e.g., ORC) to pick-up wrong symbol addresses when linker
relaxation was enabled.
This patch fixes this by running relaxation during the post-allocation
passes.
Fixes#63671
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D154501
D149522 introduced target features to LinkGraph. However, to avoid a
public dependency on MC, the features were stored in a std::vector
instead of using SubtargetFeatures directly.
Since SubtargetFeatures was moved from MC to TargetParser (D150549), we
can now use it directly to store the features. This patch implements
that and removes the (private) dependency on MC.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D153749
The relaxation algorithm used to only update offsets of relaxable edges.
This caused non-relaxable edges that appear after a relaxed instruction
to have an incorrect offset and be applied at the wrong location. This
patch fixes this by updating the offsets of all edges.
Note that this bug was caused by an incorrect translation of LLD's
relaxation algorithm. LLD always uses all edges during relaxation while
I decided to filter-out relaxable edges to prevent having to iterate
non-relaxable edges at each step. However, this had the side-effect of
only updating offsets of relaxable edges. This patch leaves the
filtering of relaxable edges as-is but iterates all edges when updating
offsets.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D153515
This is useful for contexts where shouldAddDefaultTargetPasses returns
false but that still want to perform relaxation.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D153538
Relaxable edges are created unconditionally, even when the relaxation
pass will not run. However, they were not recognized by applyFixup
causing them to not be applied.
To support configurations without the relaxation pass, this patch adds
these relaxable edges to applyFixup:
- CallRelaxable: Can be treated as R_RISCV_CALL
- AlignRelaxable: Can simply be ignored
An alternative could be to unconditionally run the relaxation pass, even
in contexts where shouldAddDefaultTargetPasses returns false. However, I
could imagine there being use cases for disabling relaxation which
wouldn't be possible anymore then.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D153541
For linker relaxation (D149526), a new edge kind (`CallRelaxable`) was
introduced. However, this new kind was not taken into account by
`PerGraphGOTAndPLTStubsBuilder_ELF_riscv`. This patch fixes this.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D150957
This patch is essentially an adaption of LLD's algorithm to JITLink.
Currently, only relaxing R_RISCV_CALL(_PLT) and R_RISCV_ALIGN is
implemented, other relocations can follow later.
From a high level, the algorithm works as follows. In the first phase
(relaxBlock), we iteratively try to relax all instructions that have a
R_RISCV_RELAX relocation:
- If, based on the current symbol values, an instruction sequence can be
relaxed (i.e., replaced by a shorter instruction), we record how many
bytes would be removed, the new instruction (Writes), and the new
relocation type (EdgeKinds).
- We keep track of the total number of bytes that got removed up to each
relocation in the RelocDeltas array. This is the cumulative sum of the
number of bytes removed for each relocation.
- Symbol values and sizes are updated based on the number of removed
bytes.
- If for any relocation, the current RelocDeltas value doesn't match the
one from the previous iteration, something changed and we need to run
another iteration as some symbols might now have different values.
In the second phase (finalizeBlockRelax), all code is moved based on
RelocDeltas, the relaxed instructions are rewritten using Writes, and
R_RISCV_ALIGN is handled (moving instructions to ensure alignment and
inserting the correct NOP-sequence if needed). Finally, edge kinds and
offsets are updated and all R_RISCV_RELAX and R_RISCV_ALIGN edges are
removed (they are not needed anymore for the fixup linking stage).
Linker relaxation is implemented as a pass and added to PreFixupPasses
in the default configuration on RISC-V.
Since linker relaxation removes instructions, the memory for blocks
should ideally be reallocated. However, I believe this is currently not
possible in JITLink. Therefore, relaxation directly modifies the memory
of blocks, reducing the number of instructions but not the size of
blocks. I'm not very familiar with JITLink's memory allocators so I
might be overlooking something here, though.
Note on testing: some of the tests rely on the debug output of
llvm-jitlink. The main reason for this is the verification of symbol
sizes (which may change due to relaxation). I don't believe this can be
done using jitlink-check checks alone.
Note that there is a slightly unrelated change that makes
Symbol::setOffset public to be able to update symbol offsets during
relaxation.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D149526
This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some
targets might use this information while linking.
One example, and the reason this patch was written, is linker relaxation
on RISC-V: different relaxations are possible depending on if the C
extension is enabled.
Note that the features are stored as `std::vector<std::string>` to prevent a
public dependency on MC. There is still a private dependency to be able to
convert SubtargetFeatures to a vector.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D149522
In the default link configuration, PLT stubs are created automatically
for R_RISCV_CALL_PLT relocations and the relocation itself is
transformed to R_RISCV_CALL (PerGraphGOTAndPLTStubsBuilder_ELF_riscv).
Only the latter is later handled when applying fixups and the former is
simply ignored.
This patch proposes to handle R_RISCV_CALL_PLT anyway when applying
fixups to support custom configurations that do not need automatic PLT
creation. An example of this is BOLT where PLT entries from the input
binary are reused (D147544).
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D148238
The various ADD/SUB relocations work by reading the current value the
relocation points to, transforming it, and then writing it back to
memory. While the current implementation writes the value back to
working memory, it reads the current value from the execution address of
the relocation. This causes at least wrong results, but often crashes,
when the addresses of working memory are not equal to execution
addresses. This patch fixes this by reading the current value from
working memory.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D147693
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.
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 commit adds support for 32 bit absolute and pc relative relocations in
ELF/i386 objects, along with simple regression tests.
Reviewed By: sgraenitz, lhames
Differential Revision: https://reviews.llvm.org/D135523
It is fine to not implement and ignore linker relaxation for now, but
we need to check the alignment. Luckily, an alignment of only 2 bytes
is the most common case when interpreting C++ code in clang-repl, and
already guaranteed by the length of compressed instructions.
Differential Revision: https://reviews.llvm.org/D129159
Logs enum name of unsupported relocation type. This also changes elf/x86 to use common util function (getELFRelocationTypeName) inside llvm object module.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D127715
This patch refactors the range checking function to make it compatible with all relocation types and supports range checking for R_RISCV_BRANCH. Moreover, it refactors the alignment check functions.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D117946
This patch supports the R_RISCV_JAL relocation.
Moreover, it will fix the extractBits function's behavior as it extracts Size + 1 bits.
In the test ELF_jal.s:
Before:
```
Hi: 4294836480
extractBits(Hi, 12, 8): 480
```
After:
```
Hi: 4294836480
extractBits(Hi, 12, 8): 224
```
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D117975
This patch supports the R_RISCV_JAL relocation.
Moreover, it will fix the extractBits function's behavior as it extracts Size + 1 bits.
In the test ELF_jal.s:
Before:
```
Hi: 4294836480
extractBits(Hi, 12, 8): 480
```
After:
```
Hi: 4294836480
extractBits(Hi, 12, 8): 224
```
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D117975
In D116573, the relocation behavior of R_RISCV_BRANCH didn't consider that branch instruction like 'bge' has a branch target address which is given as a PC-relative offset, sign-extend and multiplied by 2.
Although the target address is a 12-bits number, acctually its range is [-4096, 4094].
This patch fix it.
Differential Revision: https://reviews.llvm.org/D118151
This patch supports R_RISCV_SET* and R_RISCV_32_PCREL relocations in JITLink.
Reviewed By: StephenFan
Differential Revision: https://reviews.llvm.org/D117082
In RISCV, temporary symbols will be used to generate dwarf, eh_frame sections..., and will be placed in object code's symbol table. However, LLVM does not use names on these temporary symbols. This patch add anonymous symbols in LinkGraph for these temporary symbols.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D116475
ELF object files can contain duplicated sections (thus section symbols
as well), espeically when comdats/section groups are present. This patch
adds support for generating LinkGraph from object files that have
duplicated section names. This is the first step to properly model
comdats/section groups.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D114753
This patch makes jitlink to report an out of range error when the fixup value out of range
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D107328
This re-applies 133f86e95492b2a00b944e070878424cfa73f87c, which was reverted in
c5965a411c635106a47738b8d2e24db822b7416f while I investigated bot failures.
The original failure contained an arithmetic conversion think-o (on line 419 of
EHFrameSupport.cpp) that could cause failures on 32-bit platforms. The issue
should be fixed in this patch.
This patch makes jitlink to report an out of range error when the fixup value out of range
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D107328
Address the advice proposed at patch D105429 . Use [Low, Low+size) to represent bits.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D107250
Adds explicit narrowing casts to JITLinkMemoryManager.cpp.
Honors -slab-address option in llvm-jitlink.cpp, which was accidentally
dropped in the refactor.
This effectively reverts commit 6641d29b70993bce6dbd7e0e0f1040753d38842f.
