[all-commits] [llvm/llvm-project] 881c5e: [ELF] Add -z rel and -z rela

[Fangrui Song via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 881c5eef98a6c3fa59907ba2eefa6e8d086394a6
      https://github.com/llvm/llvm-project/commit/881c5eef98a6c3fa59907ba2eefa6e8d086394a6
  Author: Fangrui Song <maskray at google.com>
  Date:   2020-05-29 (Fri, 29 May 2020)

  Changed paths:
    M lld/ELF/Driver.cpp
    M lld/docs/ld.lld.1
    A lld/test/ELF/i386-zrel-zrela.s
    A lld/test/ELF/x86-64-zrel-zrela.s

  Log Message:
  -----------
  [ELF] Add -z rel and -z rela

LLD supports both REL and RELA for static relocations, but emits either
of REL and RELA for dynamic relocations. The relocation entry format is
specified by each psABI.

musl ld.so supports both REL and RELA. For such ld.so implementations,
REL (.rel.dyn .rel.plt) has size benefits even if the psABI chooses RELA:
sizeof(Elf64_Rel)=16 < sizeof(Elf64_Rela)=24.

* COPY, GLOB_DAT and J[U]MP_SLOT always have 0 addend. A ld.so
  implementation does not need to read the implicit addend.
  REL is strictly better.
* A RELATIVE has a non-zero addend. Such relocations can be packed
  compactly with the RELR relocation entry format, which is out of scope
  of this patch.
* For other dynamic relocation types (e.g. symbolic relocation R_X86_64_64),
  a ld.so implementation needs to read the implicit addend. REL may have
  minor performance impact, because reading implicit addends forces
  random access reads instead of being able to blast out a bunch of
  writes while chasing the relocation array.

This patch adds -z rel and -z rela to change the relocation entry format
for dynamic relocations. I have tested that a -z rel produced x86-64
executable works with musl ld.so

-z rela may be useful for debugging purposes on processors whose psABIs
specify REL as the canonical format: addends can be easily read by a tool.

Reviewed By: grimar, mcgrathr

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