[JITLink][RISCV] Ignore R_RISCV_RELAX and check R_RISCV_ALIGN

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 by

[JITLink][RISCV] Ignore R_RISCV_RELAX and check R_RISCV_ALIGN

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

show more ...

[JITLink][ELF] Log enum name of unsupported relocation type.

Logs enum name of unsupported relocation type. This also changes elf/x86 to use common util function (getELFRelocationTypeName) inside ll

[JITLink][ELF] Log enum name of unsupported relocation type.

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

show more ...

[JITLink] Fix -Wparentheses warning in R_RISCV_SUB6 case.

Perform the mask inside parentheses before applying the offset

[JITLink][RISCV] Refactor range checking and alignment checking

This patch refactors the range checking function to make it compatible with all relocation types and supports range checking for R_RIS

[JITLink][RISCV] Refactor range checking and alignment checking

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

show more ...

[JITLink] Add R_RISCV_SUB6 relocation

Add R_RISCV_SUB6 relocation

Differential Revision: https://reviews.llvm.org/D120001

[JITLink][RISCV] fix the extractBits behavior and add R_RISCV_JAL relocation.

This patch supports the R_RISCV_JAL relocation.
Moreover, it will fix the extractBits function's behavior as it extracts

[JITLink][RISCV] fix the extractBits behavior and add R_RISCV_JAL relocation.

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

show more ...

Revert "[JITLink][RISCV] fix the extractBits behavior and add R_RISCV_JAL relocation."

This reverts commit 3af7bbca4a0ef64de64b8bb38d3b167673ec60f0.

[JITLink][RISCV] fix the extractBits behavior and add R_RISCV_JAL relocation.

This patch supports the R_RISCV_JAL relocation.
Moreover, it will fix the extractBits function's behavior as it extracts

[JITLink][RISCV] fix the extractBits behavior and add R_RISCV_JAL relocation.

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

show more ...

[JITLink] Fix the incorrect relocation behavior for R_RISCV_BRANCH

In D116573, the relocation behavior of R_RISCV_BRANCH didn't consider that branch instruction like 'bge' has a branch target addres

[JITLink] Fix the incorrect relocation behavior for R_RISCV_BRANCH

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

show more ...

[JITLink][RISCV] Support R_RISCV_SET* and R_RISCV_32_PCREL relocations

This patch supports R_RISCV_SET* and R_RISCV_32_PCREL relocations in JITLink.

Reviewed By: StephenFan

Differential Revision:

[JITLink][RISCV] Support R_RISCV_SET* and R_RISCV_32_PCREL relocations

This patch supports R_RISCV_SET* and R_RISCV_32_PCREL relocations in JITLink.

Reviewed By: StephenFan

Differential Revision: https://reviews.llvm.org/D117082

show more ...

Revert "[JITLink] Add anonymous symbols in LinkGraph for unnamed temporary symbols"

This reverts commit de872382951572b70dfaefe8d77eb98d15586115.

Buildbot check error

[JITLink] Add anonymous symbols in LinkGraph for unnamed temporary symbols

In RISCV, temporary symbols will be used to generate dwarf, eh_frame sections..., and will be placed in object code's symbo

[JITLink] Add anonymous symbols in LinkGraph for unnamed temporary symbols

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

show more ...

[JITLink] Add RISCV label subtraction and addition relocations

This patch add RISCV label subtraction and addition relocations in JITLink

Differential Revision: https://reviews.llvm.org/D116794

[JITLink][ELF] Support duplicated section names from object file

ELF object files can contain duplicated sections (thus section symbols
as well), espeically when comdats/section groups are present.

[JITLink][ELF] Support duplicated section names from object file

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

show more ...

[jitlink] add R_RISCV_BRANCH to jitlink

This patch supported the R_RISCV_BRANCH relocation.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D116573

[JITLink] Add fixup value range check

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

[JITLink] Add fixup value range check

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

show more ...

Re-apply "[JITLink] Update JITLink to use ExecutorAddr rather... " with fixes.

This re-applies 133f86e95492b2a00b944e070878424cfa73f87c, which was reverted in
c5965a411c635106a47738b8d2e24db822b7416

Re-apply "[JITLink] Update JITLink to use ExecutorAddr rather... " with fixes.

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.

show more ...

Revert "[JITLink] Update JITLink to use ExecutorAddr rather than..."

This reverts commit 133f86e95492b2a00b944e070878424cfa73f87c while I investigate
the bot failures at https://lab.llvm.org/buildbo

Revert "[JITLink] Update JITLink to use ExecutorAddr rather than..."

This reverts commit 133f86e95492b2a00b944e070878424cfa73f87c while I investigate
the bot failures at https://lab.llvm.org/buildbot#builders/186/builds/3370.

show more ...

[JITLink] Update JITLink to use ExecutorAddr rather than JITTargetAddress.

ExecutorAddr is the preferred representation for executor process addresses now.

Revert "[JITLink] Add fixup value range check"

This reverts commit 17af06ba8005d6d14b0ac79ece01ecb028de9f90.

[JITLink] Add fixup value range check

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

[JITLink] Add fixup value range check

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

show more ...

[JITLink] Improve extractBits function

Address the advice proposed at patch D105429 . Use [Low, Low+size) to represent bits.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D10

[JITLink] Improve extractBits function

Address the advice proposed at patch D105429 . Use [Low, Low+size) to represent bits.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D107250

show more ...

Re-apply e50aea58d59, "Major JITLinkMemoryManager refactor". with fixes.

Adds explicit narrowing casts to JITLinkMemoryManager.cpp.

Honors -slab-address option in llvm-jitlink.cpp, which was accide

Re-apply e50aea58d59, "Major JITLinkMemoryManager refactor". with fixes.

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.

show more ...

Revert "[JITLink][ORC] Major JITLinkMemoryManager refactor."

This reverts commit e50aea58d59c8cfae807a7fee21c4227472c0678 while I
investigate bot failures.

[JITLink][ORC] Major JITLinkMemoryManager refactor.

This commit substantially refactors the JITLinkMemoryManager API to: (1) add
asynchronous versions of key operations, (2) give memory manager impl

[JITLink][ORC] Major JITLinkMemoryManager refactor.

This commit substantially refactors the JITLinkMemoryManager API to: (1) add
asynchronous versions of key operations, (2) give memory manager implementations
full control over link graph address layout, (3) enable more efficient tracking
of allocated memory, and (4) support "allocation actions" and finalize-lifetime
memory.

Together these changes provide a more usable API, and enable more powerful and
efficient memory manager implementations.

To support these changes the JITLinkMemoryManager::Allocation inner class has
been split into two new classes: InFlightAllocation, and FinalizedAllocation.
The allocate method returns an InFlightAllocation that tracks memory (both
working and executor memory) prior to finalization. The finalize method returns
a FinalizedAllocation object, and the InFlightAllocation is discarded. Breaking
Allocation into InFlightAllocation and FinalizedAllocation allows
InFlightAllocation subclassses to be written more naturally, and FinalizedAlloc
to be implemented and used efficiently (see (3) below).

In addition to the memory manager changes this commit also introduces a new
MemProt type to represent memory protections (MemProt replaces use of
sys::Memory::ProtectionFlags in JITLink), and a new MemDeallocPolicy type that
can be used to indicate when a section should be deallocated (see (4) below).

Plugin/pass writers who were using sys::Memory::ProtectionFlags will have to
switch to MemProt -- this should be straightworward. Clients with out-of-tree
memory managers will need to update their implementations. Clients using
in-tree memory managers should mostly be able to ignore it.

Major features:

(1) More asynchrony:

The allocate and deallocate methods are now asynchronous by default, with
synchronous convenience wrappers supplied. The asynchronous versions allow
clients (including JITLink) to request and deallocate memory without blocking.

(2) Improved control over graph address layout:

Instead of a SegmentRequestMap, JITLinkMemoryManager::allocate now takes a
reference to the LinkGraph to be allocated. The memory manager is responsible
for calculating the memory requirements for the graph, and laying out the graph
(setting working and executor memory addresses) within the allocated memory.
This gives memory managers full control over JIT'd memory layout. For clients
that don't need or want this degree of control the new "BasicLayout" utility can
be used to get a segment-based view of the graph, similar to the one provided by
SegmentRequestMap. Once segment addresses are assigned the BasicLayout::apply
method can be used to automatically lay out the graph.

(3) Efficient tracking of allocated memory.

The FinalizedAlloc type is a wrapper for an ExecutorAddr and requires only
64-bits to store in the controller. The meaning of the address held by the
FinalizedAlloc is left up to the memory manager implementation, but the
FinalizedAlloc type enforces a requirement that deallocate be called on any
non-default values prior to destruction. The deallocate method takes a
vector<FinalizedAlloc>, allowing for bulk deallocation of many allocations in a
single call.

Memory manager implementations will typically store the address of some
allocation metadata in the executor in the FinalizedAlloc, as holding this
metadata in the executor is often cheaper and may allow for clean deallocation
even in failure cases where the connection with the controller is lost.

(4) Support for "allocation actions" and finalize-lifetime memory.

Allocation actions are pairs (finalize_act, deallocate_act) of JITTargetAddress
triples (fn, arg_buffer_addr, arg_buffer_size), that can be attached to a
finalize request. At finalization time, after memory protections have been
applied, each of the "finalize_act" elements will be called in order (skipping
any elements whose fn value is zero) as

((char*(*)(const char *, size_t))fn)((const char *)arg_buffer_addr,
(size_t)arg_buffer_size);

At deallocation time the deallocate elements will be run in reverse order (again
skipping any elements where fn is zero).

The returned char * should be null to indicate success, or a non-null
heap-allocated string error message to indicate failure.

These actions allow finalization and deallocation to be extended to include
operations like registering and deregistering eh-frames, TLS sections,
initializer and deinitializers, and language metadata sections. Previously these
operations required separate callWrapper invocations. Compared to callWrapper
invocations, actions require no extra IPC/RPC, reducing costs and eliminating
a potential source of errors.

Finalize lifetime memory can be used to support finalize actions: Sections with
finalize lifetime should be destroyed by memory managers immediately after
finalization actions have been run. Finalize memory can be used to support
finalize actions (e.g. with extra-metadata, or synthesized finalize actions)
without incurring permanent memory overhead.

show more ...