[MC] Fix assembler infinite loop on EH table using LEB padding

[rprichard]

Summary

Fix the infinite loop reported in PR35809. It can occur with GCC-style
EH table assembly, where the compiler relies on the assembler to
calculate the offsets in the EH table.

Also see https://sourceware.org/bugzilla/show_bug.cgi?id=4029 for the
equivalent issue in the GNU assembler.

[srhines]

This looks great. Thanks for resolving this problem.

[rprichard]

Remove the RelaxAllowances behavior where an LEB fragment could be shrunk a
fixed number of times. Instead, never shrink an LEB fragment.

Also remove the uleb-optimal.s test. The LLVM assembler will output a padded
LEB for this test, but it previously would not have. The assembler is not
obligated to pad that LEB.

[• espindola]

r323934.

lib/MC/MCAssembler.cpp

bool MCAssembler::relaxLEB(MCAsmLayout &Layout, MCLEBFragment &LF) {
   uint64_t OldSize = LF.getContents().size();
   int64_t Value;
   bool Abs = LF.getValue().evaluateKnownAbsolute(Value, Layout);
   if (!Abs)
     report_fatal_error("sleb128 and uleb128 expressions must be absolute");
   SmallString<8> &Data = LF.getContents();
   Data.clear();
   raw_svector_ostream OSE(Data);
+  // The compiler can generate EH table assembly that is impossible to assemble
+  // without either adding padding to an LEB fragment or adding extra padding
+  // to a later alignment fragment. To accommodate such tables, relaxation can
+  // only increase an LEB fragment size here, not decrease it. See PR35809.
   if (LF.isSigned())
-    encodeSLEB128(Value, OSE);
+    encodeSLEB128(Value, OSE, OldSize);
   else
-    encodeULEB128(Value, OSE);
+    encodeULEB128(Value, OSE, OldSize);
   return OldSize != LF.getContents().size();
 }
 
 bool MCAssembler::relaxDwarfLineAddr(MCAsmLayout &Layout,
                                      MCDwarfLineAddrFragment &DF) {
   MCContext &Context = Layout.getAssembler().getContext();
   uint64_t OldSize = DF.getContents().size();
   int64_t AddrDelta;

test/MC/ELF/uleb-ehtable.s

+// RUN: llvm-mc -filetype=obj -triple i686-pc-linux-gnu    %s -o - | llvm-readobj -s -sd | FileCheck %s -check-prefix=CHECK -check-prefix=ELF
+// RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu  %s -o - | llvm-readobj -s -sd | FileCheck %s -check-prefix=CHECK -check-prefix=ELF
+// RUN: llvm-mc -filetype=obj -triple i386-apple-darwin9   %s -o - | llvm-readobj -s -sd | FileCheck %s -check-prefix=CHECK -check-prefix=MACHO
+// RUN: llvm-mc -filetype=obj -triple x86_64-apple-darwin9 %s -o - | llvm-readobj -s -sd | FileCheck %s -check-prefix=CHECK -check-prefix=MACHO
+
+// Test that we can assemble a GCC-like EH table that has 16381-16383 bytes of
+// non-padding data between .ttbaseref and .ttbase. The assembler must insert
+// extra padding either into the uleb128 or at the balign directive. See
+// PR35809.
+
+        .data
+        .balign 4
+foo:
+        .byte 0xff  // LPStart omitted
+        .byte 0x1   // TType encoding (uleb128)
+        .uleb128 .ttbase-.ttbaseref
+.ttbaseref:
+        .fill 128*128-1, 1, 0xcd    // call site and actions tables
+        .balign 4
+.ttbase:
+        .byte 1, 2, 3, 4
+
+// ELF:   Name: .data
+// MACHO: Name: __data
+// CHECK:      SectionData (
+// CHECK-NEXT:   0000: FF01FFFF 00CDCDCD CDCDCDCD CDCDCDCD
+// CHECK:        4000: CDCDCDCD 01020304
+// CHECK-NEXT: )