Fix bugs found during testing

Created using spr 1.3.6-beta.1

Author: pcc

lld/ELF/Arch/TargetImpl.h

@@ -46,10 +46,11 @@ inline void applyBranchToBranchOptImpl(
         [&getBranchInfo](Relocation &r,
                          uint64_t addend) -> std::pair<Relocation *, uint64_t> {
       auto *target = dyn_cast_or_null<Defined>(r.sym);
-      // We don't allow preemptible symbols (may go somewhere else),
+      // We don't allow preemptible symbols or ifuncs (may go somewhere else),
       // absolute symbols (runtime behavior unknown), non-executable memory
       // (ditto) or non-regular sections (no section data).
-      if (!target || target->isPreemptible || !target->section ||
+      if (!target || target->isPreemptible || target->isGnuIFunc() ||
+          !target->section ||
           !(target->section->flags & llvm::ELF::SHF_EXECINSTR) ||
           target->section->kind() != SectionBase::Regular)
         return {nullptr, 0};
@@ -65,7 +66,11 @@ inline void applyBranchToBranchOptImpl(
           std::pair<Relocation *, uint64_t> targetAndAddend =
               getRelocBranchInfo(r, *addend);
           if (targetAndAddend.first) {
-            while (1) {
+            // Avoid getting stuck in an infinite loop if we encounter a branch
+            // that (possibly indirectly) branches to itself. It is unlikely
+            // that more than 5 iterations will ever be needed in practice.
+            size_t iterations = 5;
+            while (iterations--) {
               std::pair<Relocation *, uint64_t> nextTargetAndAddend =
                   getRelocBranchInfo(*targetAndAddend.first,
                                      targetAndAddend.second);

lld/ELF/Arch/X86_64.cpp

@@ -1178,8 +1178,15 @@ static std::optional<uint64_t> getControlTransferAddend(InputSection &is,
   // to branch into the middle of a PLT. For example, relative vtable
   // relocations use PLT32 and 0 or a positive value as the addend but still are
   // used to branch to the symbol.
-  if (r.type == R_X86_64_PLT32)
+  //
+  // STT_SECTION symbols are a special case on x86 because the LLVM assembler
+  // uses them for branches to local symbols which are assembled as referring to
+  // the section symbol with the addend equal to the symbol value - 4.
+  if (r.type == R_X86_64_PLT32) {
+    if (r.sym->isSection())
+      return r.addend + 4;
     return 0;
+  }
   return std::nullopt;
 }
 
@@ -1204,11 +1211,18 @@ static std::pair<Relocation *, uint64_t> getBranchInfo(InputSection &is,
 
 static void mergeControlTransferRelocations(Relocation &r1,
                                             const Relocation &r2) {
-  r1.expr = r2.expr;
-  r1.sym = r2.sym;
+  // The isSection() check handles the STT_SECTION case described above.
+  // In that case the original addend is irrelevant because it referred to an
+  // offset within the original target section so we overwrite it.
+  //
   // The +4 is here to compensate for r2.addend which will likely be -4,
   // but may also be addend-4 in case of a PC32 branch to symbol+addend.
-  r1.addend += r2.addend + 4;
+  if (r1.sym->isSection())
+    r1.addend = r2.addend;
+  else
+    r1.addend += r2.addend + 4;
+  r1.expr = r2.expr;
+  r1.sym = r2.sym;
 }
 
 void X86_64::applyBranchToBranchOpt() const {

lld/test/ELF/x86-64-branch-to-branch.s

@@ -42,6 +42,12 @@ jmp f1
 # B2B-NEXT: jmp {{.*}} <f3>
 # NOB2B-NEXT: jmp {{.*}} <f2{{.*}}>
 jmp f2
+# This will assemble to a relocation pointing to an STT_SECTION for .text.f4
+# with an addend, which looks similar to the relative vtable cases above but
+# requires different handling of the addend so that we don't think this is
+# branching to the `jmp f3` at the start of the target section.
+# CHECK-NEXT: jmp {{.*}} <f4{{.*}}>
+jmp f4
 
 .section .text.f1,"ax"
 .globl f1
@@ -58,4 +64,10 @@ jmp f3
 .section .text.f3,"ax"
 .globl f3
 f3:
+# Test that a self-branch doesn't trigger an infinite loop.
+jmp f3
+
+.section .text.f4,"ax"
+jmp f3
+f4:
 ret