https://sourceware.org/bugzilla/show_bug.cgi?id=27180
Bug ID: 27180
Summary: RISC-V far relocations for auipc instructions may
cause segfault with --emit-relocs
Product: binutils
Version: 2.35.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jwerner at chromium dot org
Target Milestone: ---
I have run into a segfault in GNU ld for the RISC-V architecture. I'm using
2.35.1, but I also briefly tried out the latest Git tree and saw it there as
well. The following minimal testcase can reproduce it:
======== test.c ========
extern int mysymbol[0];
int *_start(void) {
return mysymbol;
}
========================
======= test.ld ========
ENTRY(_start)
SECTIONS
{
mysymbol = 0x1000;
.text 0x90000000 : {
*(.text)
}
}
========================
$ riscv64-elf-gcc -nostdlib -T test.ld -Wl,--emit-relocs -mcmodel=medany -o
test test.c
collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
compilation terminated.
I have debugged the segfault a bit and found that it happens at `rh =
elf_sym_hashes (input_bfd)[indx];` in elflink.c:11232, because indx is
completely out of range. The problem is that this code assumes that r_symndx
(computed from `irela->r_info >> r_sym_shift`) can always be trusted to be a
symbol index. However, for some absolute relocations in the RISC-V
architecture, it is actually an absolute offset.
In my testcase, the problematic relocation starts out as an R_RISCV_PCREL_HI20
relocation (where the high 32 bytes would be a symbol index, so this code would
work correctly). However, when calling into the riscv_elf_relocate_section()
backend, the relocation ends up being transformed into an R_RISCV_HI20 absolute
relocation, where the high 32 bytes of r_info are simply an absolute address.
(It's possible that this bug also exists for normal R_RISCV_HI20 relocations in
the source file, or maybe that case would've been caught earlier and it's only
the late transformation of the relocation that causes the problem... I didn't
test that far.)
--
You are receiving this mail because:
You are on the CC list for the bug.
