Relax relocation type checking in a non-ALLOC section.

[ruiu]

Summary

Even though it doesn't make sense, there seems to be multiple programs
in the wild that create PC-relative relocations in non-ALLOC sections.
This is caused by the negligence of GNU linkers to not report any errors
for such relocations.

Currently, lld emits warnings against such relocations and exits.
So, you cannot link any program that contains wrong relocations until
you fix an issue in a program that generates wrong ELF files. It's often
impractical because it isn't always easy to fix a problem in a ELF-
generating program.

This patch relaxes the error checking and emit a warning instead.

[ruiu]

• fix typos in test

[ruiu]

• updated as per Rafael's comment

[ruiu]

• early continue

[ruiu]

• address a review comment

[ruiu]

• keep reporting errors if not R_ABS nor R_PC
• restore the original test for an unknown relocation type

lld/trunk/ELF/InputSection.cpp

 // So, we handle relocations for non-alloc sections directly in this
 // function as a performance optimization.
 template <class ELFT, class RelTy>
 void InputSection::relocateNonAlloc(uint8_t *Buf, ArrayRef<RelTy> Rels) {
   const unsigned Bits = sizeof(typename ELFT::uint) * 8;
 
   for (const RelTy &Rel : Rels) {
     RelType Type = Rel.getType(Config->IsMips64EL);
+
+    // GCC 8.0 or earlier have a bug that they emit R_386_GOTPC relocations
+    // against _GLOBAL_OFFSET_TABLE_ for .debug_info. The bug has been fixed
+    // in 2017 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630), but we
+    // need to keep this bug-compatible code for a while.
+    if (Config->EMachine == EM_386 && Type == R_386_GOTPC)
+      continue;
+
     uint64_t Offset = getOffset(Rel.r_offset);
     uint8_t *BufLoc = Buf + Offset;
     int64_t Addend = getAddend<ELFT>(Rel);
     if (!RelTy::IsRela)
       Addend += Target->getImplicitAddend(BufLoc, Type);
 
     Symbol &Sym = getFile<ELFT>()->getRelocTargetSym(Rel);
     RelExpr Expr = Target->getRelExpr(Type, Sym, BufLoc);
     if (Expr == R_NONE)
       continue;
-    if (Expr != R_ABS) {
-      // GCC 8.0 or earlier have a bug that it emits R_386_GOTPC relocations
-      // against _GLOBAL_OFFSET_TABLE for .debug_info. The bug seems to have
-      // been fixed in 2017: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630,
-      // but we need to keep this bug-compatible code for a while.
-      if (Config->EMachine == EM_386 && Type == R_386_GOTPC)
-        continue;
 
-      error(getLocation<ELFT>(Offset) + ": has non-ABS relocation " +
-            toString(Type) + " against symbol '" + toString(Sym) + "'");
+    if (Expr != R_ABS) {
+      std::string Msg = getLocation<ELFT>(Offset) +
+                        ": has non-ABS relocation " + toString(Type) +
+                        " against symbol '" + toString(Sym) + "'";
+      if (Expr != R_PC) {
+        error(Msg);
         return;
       }
 
+      // If the control reaches here, we found a PC-relative relocation in a
+      // non-ALLOC section. Since non-ALLOC section is not loaded into memory
+      // at runtime, the notion of PC-relative doesn't make sense here. So,
+      // this is a usage error. However, GNU linkers historically accept such
+      // relocations without any errors and relocate them as if they were at
+      // address 0. For bug-compatibilty, we accept them with warnings. We
+      // know Steel Bank Common Lisp as of 2018 have this bug.
+      warn(Msg);
+      Target->relocateOne(BufLoc, Type,
+                          SignExtend64<Bits>(Sym.getVA(Addend - Offset)));
+      continue;
+    }
+
     if (Sym.isTls() && !Out::TlsPhdr)
       Target->relocateOne(BufLoc, Type, 0);
     else
       Target->relocateOne(BufLoc, Type, SignExtend64<Bits>(Sym.getVA(Addend)));
   }
 }
 
 template <class ELFT>

lld/trunk/test/ELF/i386-debug-noabs.test

 # REQUIRES: x86
 
 # RUN: yaml2obj %s -o %t.o
-# RUN: ld.lld %t.o -o %t.exe
+# RUN: ld.lld %t.o -o %t.exe --entry 0 --fatal-warnings
 
 ## This is for https://bugs.llvm.org//show_bug.cgi?id=34852. GCC 8.0 or
 ## earlier have a bug which creates non-absolute R_386_GOTPC relocations
 ## in non-allocated sections. It is illegal, but we want to make sure that
 ## lld skips them instead of reporting errors.
 
 --- !ELF
 FileHeader:

lld/trunk/test/ELF/non-abs-reloc.s

 // REQUIRES: x86
 // RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
-// RUN: not ld.lld %t.o -o %t.so -shared 2>&1 | FileCheck %s
-// CHECK: {{.*}}:(.dummy+0x0): has non-ABS relocation R_X86_64_GOTPCREL against symbol 'foo'
+// RUN: ld.lld %t.o -o %t 2>&1 | FileCheck %s
+// CHECK: (.nonalloc+0x1): has non-ABS relocation R_X86_64_PC32 against symbol '_start'
+// CHECK: (.nonalloc+0x6): has non-ABS relocation R_X86_64_PC32 against symbol '_start'
+
+// RUN: llvm-objdump -D %t | FileCheck --check-prefix=DISASM %s
+// DISASM:      Disassembly of section .nonalloc:
+// DISASM-NEXT: .nonalloc:
+// DISASM-NEXT: 0: {{.*}}  callq {{.*}} <_start>
+// DISASM-NEXT: 5: {{.*}}  callq {{.*}} <_start>
 
 .globl _start
 _start:
   nop
 
-.section .dummy
-  .long foo@gotpcrel
+.section .nonalloc
+  call _start
+  call _start