[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/24678] New: RISC-V pcrel relocs and abs global pointer variable
From: |
wilson at gcc dot gnu.org |
Subject: |
[Bug ld/24678] New: RISC-V pcrel relocs and abs global pointer variable |
Date: |
Thu, 13 Jun 2019 22:53:46 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=24678
Bug ID: 24678
Summary: RISC-V pcrel relocs and abs global pointer variable
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Reported via IRC.
Compiling a trivial program as PIE, I get
hifiveu017:1201$ gcc -pie -fpic tmp.c
hifiveu017:1202$ readelf -s a.out | grep global_pointer
65: 0000000000002800 0 NOTYPE GLOBAL DEFAULT ABS __global_pointer$
hifiveu017:1203$
This uses Scrt1.o which has
0000000000000038 <.Lload_gp>:
38: 00000197 auipc gp,0x0
38: R_RISCV_PCREL_HI20 __global_pointer$
3c: 00018193 mv gp,gp
3c: R_RISCV_PCREL_LO12_I .L0
40: 8082 ret
...
So we end up processing pc-relative relocs against a SHN_ABS symbol, which
isn't quite right. This does work in practice because __global_pointer$ is not
actually a SHN_ABS symbol. It just gets marked that way because of the way we
created it in a linker script. But this inconsistency is breaking lld which
insists that pc-relative relocs can't be resolved against SHN_ABS symbols.
We should figure out how to get the __global_pointer$ symbol into an
appropriate section. And we should consider warning for pc-relative relocs
against absolute symbols.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/24678] New: RISC-V pcrel relocs and abs global pointer variable,
wilson at gcc dot gnu.org <=