[Bug ld/22972] New: [SPARC] Mixing GOT and GOTDATA_OP relocations can lead to broken binaries

[jrtc27 at jrtc27 dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22972

            Bug ID: 22972
           Summary: [SPARC] Mixing GOT and GOTDATA_OP relocations can lead
                    to broken binaries
           Product: binutils
           Version: 2.30
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: jrtc27 at jrtc27 dot com
                CC: ebotcazou at gcc dot gnu.org, glaubitz at physik dot 
fu-berlin.de
  Target Milestone: ---
            Target: sparc64-linux-gnu

Created attachment 10896
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10896&action=edit
Reproduction

Currently, if the symbol is defined in the output, non-preemptible and within
+/- 4 GiB of the relocation, ld optimises GOTDATA_OP relocations to be GOTDATA,
i.e. an add of (sym-_GLOBAL_OFFSET_TABLE_) rather than a load of
(address@hidden). After the fix for 22832, when the
R_SPARC_GOTDATA_OP (the load) instruction is rewritten, if the symbol is not
dynamic, an R_SPARC_NONE is decided upon for the GOT slot (and zero addend) and
h->got.offset is tagged with 1. However, if an object file seen later during
linking uses the older R_SPARC_GOT22/10 relocations for the same symbol, they
will see that h->got.offset is 1 and assume that this means the GOT relocation
has been correctly emitted, but in fact it has not; it instead needs an
R_SPARC_RELATIVE with the addend equal to the symbol's value. Thus, the
R_SPARC_NONE decision must be delayed until all input files have been
processed.

This bug was discovered thanks to OpenSSL's test suite
(https://github.com/openssl/openssl/issues/5586); the attached script
demonstrates the problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.