[ELF] Add -z rel and -z rela

[MaskRay]

Summary

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.

[grimar]

Generally looks fine I think. Few comments from me.

lld/ELF/Driver.cpp

852

It would be more consistent with the rest code to use StringRef comparsion instead of strcmp.
E.g:

static GnuStackKind getZGnuStack(opt::InputArgList &args) {
  for (auto *arg : args.filtered_reverse(OPT_z)) {
    if (StringRef("execstack") == arg->getValue())
      return GnuStackKind::Exec;
...

lld/test/ELF/i386-zrela.s

1 ↗

(On Diff #265940)

Perhaps, the name of the test should be i386-zrel-zrela.s since you test both?
(this and all other comments also applies for x86-64-zrel.s)

30 ↗

(On Diff #265940)

I think you need to have just -z rela too.

43 ↗

(On Diff #265940)

Does it worth to show what happens for R_386_RELATIVE?

[MaskRay]

Address comments

lld/test/ELF/i386-zrela.s

30 ↗

(On Diff #265940)

This is to show that the last of rel and rela wins.

43 ↗

(On Diff #265940)

Worthy. Added

[grimar]

LGTM with a last comment addressed.
Probably hold this a bit to give other people chance to look too.

lld/test/ELF/i386-zrela.s

30 ↗

(On Diff #265940)

Yes, I understood that. I mean you have "-z rel -z rela" case, what is fine, but do not have a case when "-z rela" is just alone.
(what is actually a more real use case)

[MaskRay]

In D80496#2054133, @grimar wrote:

LGTM with a last comment addressed.
Probably hold this a bit to give other people chance to look too.

This may be a display problem. In the latest revision https://reviews.llvm.org/D80496?id=266043 , the files are i386-zrel-zrela.s and x86-64-zrel-zrela.s , but Phabricator seems to display the old names (probably to associate with the old comments).

I'll definitely wait a bit longer to get more input. FWIW I also asked binutils and glibc https://sourceware.org/pipermail/binutils/2020-May/111244.html (it may be difficult for them due to how they organize code...)
asked FreeBSD, mentioned it in a kernel thread, etc...

[grimar]

In D80496#2055695, @MaskRay wrote:

In D80496#2054133, @grimar wrote:

LGTM with a last comment addressed.
Probably hold this a bit to give other people chance to look too.

This may be a display problem. In the latest revision https://reviews.llvm.org/D80496?id=266043 , the files are i386-zrel-zrela.s and x86-64-zrel-zrela.s , but Phabricator seems to display the old names (probably to associate with the old comments).

I see the new names using the following raw link "https://reviews.llvm.org/D80496". The "https://reviews.llvm.org/D80496?id=266043" refers to the previous diff I believe.

[MaskRay]

My /opt/google/chrome/chrome

[10] .rela.dyn         RELA            0000000000013030 013030 edc498 18   A  5   0  8

.rela.dyn has 649225 R_X86_64_RELATIVE and 1632 R_X86_64_{64,GLOB_DAT,JUMP_SLOT}.

This feature barely passes my bar for an option. I'd like to hear more from @arichardson how changing REL/RELA can help debugging.

[mcgrathr]

LGTM. It might be worth mentioning in the doc/comment that REL format cannot pack the full range of addend values for all reloc types, but this only affects reloc types that lld doesn't support emitting as dynamic relocs since they are only used for TEXTRELs.

[MaskRay]

Update comment

[MaskRay]

In D80496#2060948, @mcgrathr wrote:

LGTM. It might be worth mentioning in the doc/comment that REL format cannot pack the full range of addend values for all reloc types, but this only affects reloc types that lld doesn't support emitting as dynamic relocs since they are only used for TEXTRELs.

My understanding is that text relocations describes dynamic relocations in non-SHF_WRITE sections. I do not say text relocations because we disallow such dynamic relocations from SHF_WRITE sections as well.

[mcgrathr]

In D80496#2061684, @MaskRay wrote:

In D80496#2060948, @mcgrathr wrote:

LGTM. It might be worth mentioning in the doc/comment that REL format cannot pack the full range of addend values for all reloc types, but this only affects reloc types that lld doesn't support emitting as dynamic relocs since they are only used for TEXTRELs.

My understanding is that text relocations describes dynamic relocations in non-SHF_WRITE sections. I do not say text relocations because we disallow such dynamic relocations from SHF_WRITE sections as well.

That's right. My point is that the existing documentation describes it as an unknown mystery while RELA even exists. The reason that RELA exists for dynamic relocations is because of the non-full-width reloc types. Since lld doesn't support any such cases, the original rationale for RELA for dynamic relocations never applies in lld. If lld did support those, then -z rel logic would need to check for and diagnose cases where REL format cannot represent the addend for a particular reloc. Since lld doesn't support TEXTRELs, those never come up and -z rel can always work.

lld/ELF/Driver.cpp

return s == "combreloc" || s == "copyreloc" || s == "defs" ||
          s == "global" || s == "hazardplt" || s == "ifunc-noplt" ||
          s == "initfirst" || s == "interpose" ||
          s == "keep-text-section-prefix" || s == "lazy" || s == "muldefs" ||
          s == "separate-code" || s == "separate-loadable-segments" ||
          s == "nocombreloc" || s == "nocopyreloc" || s == "nodefaultlib" ||
          s == "nodelete" || s == "nodlopen" || s == "noexecstack" ||
          s == "nognustack" || s == "nokeep-text-section-prefix" ||
          s == "norelro" || s == "noseparate-code" || s == "notext" ||
-         s == "now" || s == "origin" || s == "pac-plt" || s == "relro" ||
-         s == "retpolineplt" || s == "rodynamic" || s == "shstk" ||
-         s == "text" || s == "undefs" || s == "wxneeded" ||
-         s.startswith("common-page-size=") || s.startswith("max-page-size=") ||
-         s.startswith("stack-size=");
+         s == "now" || s == "origin" || s == "pac-plt" || s == "rel" ||
+         s == "rela" || s == "relro" || s == "retpolineplt" ||
+         s == "rodynamic" || s == "shstk" || s == "text" || s == "undefs" ||
+         s == "wxneeded" || s.startswith("common-page-size=") ||
+         s.startswith("max-page-size=") || s.startswith("stack-size=");
 }
 
 // Report an error for an unknown -z option.
 static void checkZOptions(opt::InputArgList &args) {
   for (auto *arg : args.filtered(OPT_z))
     if (!isKnownZFlag(arg->getValue()))
       error("unknown -z value: " + StringRef(arg->getValue()));
 }
static std::vector<StringRef> getSymbolOrderingFile(MemoryBufferRef mb) {
   SetVector<StringRef> names;
   for (StringRef s : args::getLines(mb))
     if (!names.insert(s) && config->warnSymbolOrdering)
       warn(mb.getBufferIdentifier() + ": duplicate ordered symbol: " + s);
 
   return names.takeVector();
 }
 
+static bool getIsRela(opt::InputArgList &args) {
+  // If -z rel or -z rela is specified, use the last option.
+  for (auto *arg : args.filtered_reverse(OPT_z)) {
+    StringRef s(arg->getValue());
+    if (s == "rel")
+      return false;
+    if (s == "rela")
+      return true;
+  }
+
+  // Otherwise use the psABI defined relocation entry format.
+  uint16_t m = config->emachine;
+  return m == EM_AARCH64 || m == EM_AMDGPU || m == EM_HEXAGON || m == EM_PPC ||
+         m == EM_PPC64 || m == EM_RISCV || m == EM_X86_64;
+}
+
 static void parseClangOption(StringRef opt, const Twine &msg) {
   std::string err;
   raw_string_ostream os(err);
 
   const char *argv[] = {config->progName.data(), opt.data()};
   if (cl::ParseCommandLineOptions(2, argv, "", &os))
     return;
   os.flush();
static void setConfigs(opt::InputArgList &args) {
   config->endianness = config->isLE ? endianness::little : endianness::big;
   config->isMips64EL = (k == ELF64LEKind && m == EM_MIPS);
   config->isPic = config->pie || config->shared;
   config->picThunk = args.hasArg(OPT_pic_veneer, config->isPic);
   config->wordsize = config->is64 ? 8 : 4;
 
   // ELF defines two different ways to store relocation addends as shown below:
   //
-  //  Rel:  Addends are stored to the location where relocations are applied.
+  //  Rel: Addends are stored to the location where relocations are applied. It
+  //  cannot pack the full range of addend values for all relocation types, but
+  //  this only affects relocation types that we don't support emitting as
+  //  dynamic relocations (see getDynRel).
   //  Rela: Addends are stored as part of relocation entry.
   //
   // In other words, Rela makes it easy to read addends at the price of extra
-  // 4 or 8 byte for each relocation entry. We don't know why ELF defined two
-  // different mechanisms in the first place, but this is how the spec is
-  // defined.
-  //
-  // You cannot choose which one, Rel or Rela, you want to use. Instead each
-  // ABI defines which one you need to use. The following expression expresses
-  // that.
-  config->isRela = m == EM_AARCH64 || m == EM_AMDGPU || m == EM_HEXAGON ||
-                   m == EM_PPC || m == EM_PPC64 || m == EM_RISCV ||
-                   m == EM_X86_64;
+  // 4 or 8 byte for each relocation entry.
+  //
+  // We pick the format for dynamic relocations according to the psABI for each
+  // processor, but a contrary choice can be made if the dynamic loader
+  // supports.
+  config->isRela = getIsRela(args);
 
   // If the output uses REL relocations we must store the dynamic relocation
   // addends to the output sections. We also store addends for RELA relocations
   // if --apply-dynamic-relocs is used.
   // We default to not writing the addends when using RELA relocations since
   // any standard conforming tool can find it in r_addend.
   config->writeAddends = args.hasFlag(OPT_apply_dynamic_relocs,
                                       OPT_no_apply_dynamic_relocs, false) ||

lld/docs/ld.lld.1

 .Dv DF_ORIGIN
 flag to indicate that the object requires
 $ORIGIN
 processing.
 .Pp
 .It Cm pac-plt
 AArch64 only, use pointer authentication in PLT.
 .Pp
+.It Cm rel
+Use REL format for dynamic relocations.
+.Pp
+.It Cm rela
+Use RELA format for dynamic relocations.
+.Pp
 .It Cm retpolineplt
 Emit retpoline format PLT entries as a mitigation for CVE-2017-5715.
 .Pp
 .It Cm rodynamic
 Make the
 .Li .dynamic
 section read-only.
 The

lld/test/ELF/i386-zrel-zrela.s

+# REQUIRES: x86
+## The i386 psABI uses Elf64_Rela relocation entries. We produce
+## Elf32_Rel dynamic relocations by default, but can use Elf32_Rela with -z rela.
+
+# RUN: llvm-mc -filetype=obj -triple=i386 %s -o %t.o
+# RUN: ld.lld -shared %t.o -o %t.so
+# RUN: llvm-readobj -d -r -x .data %t.so | FileCheck --check-prefix=REL %s
+# RUN: ld.lld -shared -z rel %t.o -o %t1.so
+# RUN: llvm-readobj -d -r -x .data %t1.so | FileCheck --check-prefix=REL %s
+
+# REL:      REL      {{.*}}
+# REL-NEXT: RELSZ    32 (bytes)
+# REL-NEXT: RELENT   8 (bytes)
+# REL-NEXT: RELCOUNT 1
+# REL-NEXT: JMPREL   {{.*}}
+# REL-NEXT: PLTRELSZ 8 (bytes)
+# REL-NEXT: PLTGOT   {{.*}}
+# REL-NEXT: PLTREL   REL{{$}}
+# REL:      .rel.dyn {
+# REL-NEXT:   R_386_RELATIVE - 0x0
+# REL-NEXT:   R_386_GLOB_DAT func 0x0
+# REL-NEXT:   R_386_TLS_TPOFF tls 0x0
+# REL-NEXT:   R_386_32 _start 0x0
+# REL-NEXT: }
+# REL-NEXT: .rel.plt {
+# REL-NEXT:   R_386_JUMP_SLOT func 0x0
+# REL-NEXT: }
+
+# REL:      Hex dump of section '.data':
+# REL-NEXT: 0x000042cc cc420000 2a000000
+
+# RUN: ld.lld -shared -z rel -z rela %t.o -o %t2.so
+# RUN: llvm-readobj -d -r %t2.so | FileCheck --check-prefix=RELA %s
+
+# RELA:      RELA      {{.*}}
+# RELA-NEXT: RELASZ    48 (bytes)
+# RELA-NEXT: RELAENT   12 (bytes)
+# RELA-NEXT: RELACOUNT 1
+# RELA-NEXT: JMPREL    {{.*}}
+# RELA-NEXT: PLTRELSZ  12 (bytes)
+# RELA-NEXT: PLTGOT    {{.*}}
+# RELA-NEXT: PLTREL    RELA
+# RELA:      .rela.dyn {
+# RELA-NEXT:   R_386_RELATIVE - 0x42EC
+# RELA-NEXT:   R_386_GLOB_DAT func 0x0
+# RELA-NEXT:   R_386_TLS_TPOFF tls 0x2A
+# RELA-NEXT:   R_386_32 _start 0x2A
+# RELA-NEXT: }
+# RELA-NEXT: .rela.plt {
+# RELA-NEXT:   R_386_JUMP_SLOT func 0x0
+# RELA-NEXT: }
+
+.globl _start
+_start:
+  call func@PLT
+  movl func@GOT(%eax), %eax
+
+.section .text1,"awx"
+  movl %gs:tls@NTPOFF+42, %eax
+
+.data
+  .long .data
+  .long _start+42

lld/test/ELF/x86-64-zrel-zrela.s

+# REQUIRES: x86
+## The x86-64 psABI uses Elf64_Rela relocation entries. We produce
+## Elf64_Rel dynamic relocations by default, but can use Elf64_Rel with -z rel.
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t.o
+# RUN: ld.lld -shared %t.o -o %t.so
+# RUN: llvm-readobj -d -r %t.so | FileCheck --check-prefix=RELA %s
+# RUN: ld.lld -shared -z rela %t.o -o %t1.so
+# RUN: llvm-readobj -d -r %t1.so | FileCheck --check-prefix=RELA %s
+
+# RELA:      RELA      {{.*}}
+# RELA-NEXT: RELASZ    72 (bytes)
+# RELA-NEXT: RELAENT   24 (bytes)
+# RELA-NEXT: RELACOUNT 1
+# RELA-NEXT: JMPREL    {{.*}}
+# RELA-NEXT: PLTRELSZ  24 (bytes)
+# RELA-NEXT: PLTGOT    {{.*}}
+# RELA-NEXT: PLTREL    RELA
+# RELA:      .rela.dyn {
+# RELA-NEXT:   R_X86_64_RELATIVE - 0x3428
+# RELA-NEXT:   R_X86_64_GLOB_DAT func 0x0
+# RELA-NEXT:   R_X86_64_64 _start 0x2A
+# RELA-NEXT: }
+# RELA-NEXT: .rela.plt {
+# RELA-NEXT:   R_X86_64_JUMP_SLOT func 0x0
+# RELA-NEXT: }
+
+# RUN: ld.lld -shared -z rela -z rel %t.o -o %t2.so
+# RUN: llvm-readobj -d -r -x .data %t2.so | FileCheck --check-prefix=REL %s
+
+# REL:      REL      {{.*}}
+# REL-NEXT: RELSZ    48 (bytes)
+# REL-NEXT: RELENT   16 (bytes)
+# REL-NEXT: RELCOUNT 1
+# REL-NEXT: JMPREL   {{.*}}
+# REL-NEXT: PLTRELSZ 16 (bytes)
+# REL-NEXT: PLTGOT   {{.*}}
+# REL-NEXT: PLTREL   REL{{$}}
+# REL:      .rel.dyn {
+# REL-NEXT:   R_X86_64_RELATIVE - 0x0
+# REL-NEXT:   R_X86_64_GLOB_DAT func 0x0
+# REL-NEXT:   R_X86_64_64 _start 0
+# REL-NEXT: }
+# REL-NEXT: .rel.plt {
+# REL-NEXT:   R_X86_64_JUMP_SLOT func 0x0
+# REL-NEXT: }
+
+# REL:      Hex dump of section '.data':
+# REL-NEXT: 0x00003408 08340000 00000000 2a000000 00000000
+
+.globl _start
+_start:
+  call func@PLT
+  movq func@GOTPCREL(%rip), %rax
+
+.data
+  .quad .data
+  .quad _start+42