[Bug ld/20475] New: Linking PIC executables with a linker script that does not place _GLOBAL_OFFSET_TABLE_ results in incorrect relocation

[whitequark at whitequark dot org]

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.