[all-commits] [llvm/llvm-project] 03ffe5: [ELF][PPC64] Don't perform toc-indirect to toc-rel...

[Fangrui Song via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 03ffe5860549e97a0f2d8262b100e8910f61c528
      https://github.com/llvm/llvm-project/commit/03ffe5860549e97a0f2d8262b100e8910f61c528
  Author: Fangrui Song <maskray at google.com>
  Date:   2020-04-28 (Tue, 28 Apr 2020)

  Changed paths:
    M lld/ELF/InputSection.cpp
    A lld/test/ELF/ppc64-toc-relax2.s

  Log Message:
  -----------
  [ELF][PPC64] Don't perform toc-indirect to toc-relative relaxation for R_PPC64_TOC16_HA not followed by R_PPC64_TOC16_LO_DS

The current implementation assumes that R_PPC64_TOC16_HA is always followed
by R_PPC64_TOC16_LO_DS. This can break with:

// Load the address of the TOC entry, instead of the value stored at that address
  addis 3, 2, .LC0 at tloc@ha  # R_PPC64_TOC16_HA
  addi  3, 3, .LC0 at tloc@l   # R_PPC64_TOC16_LO
  blr

which is used by boringssl's util/fipstools/delocate/delocate.go
https://github.com/google/boringssl/blob/master/crypto/fipsmodule/FIPS.md has some documentation.
In short, this tool converts an assembly file to avoid any potential relocations.
The distance to an input .toc is not a constant after linking, so the assembly cannot use an `addis;ld` pair.
Instead, delocate changes the code to jump to a stub (`addis;addi`) which loads the TOC entry address.

Reviewed By: sfertile

Differential Revision: https://reviews.llvm.org/D78431