https://sourceware.org/bugzilla/show_bug.cgi?id=33236
Bug ID: 33236
Summary: ld riscv: Relocatable linking challenge with
R_RISCV_ALIGN
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Updated
https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation to
mention this issue:
A specific issue arises in relocatable linking when a section that does not use
linker relaxation is preceded by a section that does.
Without linker relaxation enabled for a particular relocatable file or section
(e.g., using .option norelax), the assembler will not generate R_RISCV_ALIGN
relocations for alignment directives. This becomes problematic in a two-stage
linking process:
cat > a.s <<e
.globl _start
_start:
call foo
.section .text1,"ax"
.globl foo
foo:
e
cat > b.s <<e
.option push
.option norelax
# Assembler will not generate R_RISCV_ALIGN here
.balign 8
b0:
.word 0x3a393837
.option pop
e
clang --target=riscv64 -mrelax -c a.s b.s
# Single-stage linking
ld.lld a.o b.o -o ab
# Two-stage linking
ld.lld -r a.o b.o -o ab.o
ld.lld ab.o -o ab.r
When ab.o is linked into an executable, the preceding relaxed section (a.o's
content) might shrink. Since there's no R_RISCV_ALIGN relocation in b.o for the
linker to act upon, the .word 0x3a393837 data in b.o may end up unaligned in
the final executable. This produces an output that differs from a direct,
single-stage link of ld.lld a.o b.o -o ab, which would correctly align the
data.
This issue likely doesn't lead to significant problems in practice, primarily
due to these factors:
* Infrequent use of relocatable linking (ld -r).
* Rarity of data within text sections. It's even less frequent for such data to
reside at the beginning of a section, or so early in a section that there isn't
any preceding linker-relaxable instruction.
To address the issue, I am modifying LLD to synthesize an `R_RISCV_ALIGN`
relocation at the beginning of a text section with an explicit alignment
requirement. it would provide the linker with the necessary handle to adjust
that section's start address and potentially insert or remove padding to
maintain the desired alignment.
See also this LLVM assembler change
https://github.com/llvm/llvm-project/pull/150816
--
You are receiving this mail because:
You are on the CC list for the bug.
