https://sourceware.org/bugzilla/show_bug.cgi?id=20475
Bug ID: 20475
Summary: Linking PIC executables with a linker script that does
not place _GLOBAL_OFFSET_TABLE_ results in incorrect
relocation
Product: binutils
Version: 2.25
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: whitequark at whitequark dot org
Target Milestone: ---
I am using ld 2.25.1 built for or1k-elf target, and linking code built with
-fPIC. On OR1K in PIC mode, addresses of global data are gathered with the
following code (generated by the OR1K clang port):
.Ltmp2:
l.movhi r3, gotpchi(_GLOBAL_OFFSET_TABLE_+(.Ltmp2-.L0$pb))
.Ltmp3:
l.ori r3, r3, gotpclo(_GLOBAL_OFFSET_TABLE_+(.Ltmp3-.L0$pb))
l.add r3, r9, r3
l.movhi r4, gotoffhi(x)
l.ori r4, r4, gotofflo(x)
l.add r3, r4, r3
If I am using a linker script that does not explicitly do anything to the .got*
sections, then it lays out the output ELF file as follows (without emitting any
diagnostic message):
40047258 l d .got 00000000 .got
40047264 l d .got.plt 00000000 .got.plt
40047264 l O .got.plt 00000000 _GLOBAL_OFFSET_TABLE_
This, of course, breaks the code above, because the gotoffhi/lo relocations
calculate the offset from the start of the .got section, but the
_GLOBAL_OFFSET_TABLE_ symbol points at the end of the .got.plt section.
The following addition to the linker script rectifies the problem:
.got : {
_GLOBAL_OFFSET_TABLE_ = .;
*(.got)
} > runtime
.got.plt : {
*(.got.plt)
} > runtime
However, (1) I have never seen linker scripts that explicitly place
_GLOBAL_OFFSET_TABLE_, and (2) above all else, this behavior seems clearly
wrong. From what I can see, I think this is a target-specific OR1K bug, but I
am not sure.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
