[llvm] r323934 - [MC] Fix assembler infinite loop on EH table using LEB padding.

[Rafael Espindola via llvm-commits]

Author: rafael
Date: Wed Jan 31 16:25:19 2018
New Revision: 323934

URL: http://llvm.org/viewvc/llvm-project?rev=323934&view=rev
Log:
[MC] Fix assembler infinite loop on EH table using LEB padding.

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.

Patch by Ryan Prichard!

Added:
    llvm/trunk/test/MC/ELF/uleb-ehtable.s
Modified:
    llvm/trunk/lib/MC/MCAssembler.cpp

Modified: llvm/trunk/lib/MC/MCAssembler.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/MCAssembler.cpp?rev=323934&r1=323933&r2=323934&view=diff
==============================================================================
--- llvm/trunk/lib/MC/MCAssembler.cpp (original)
+++ llvm/trunk/lib/MC/MCAssembler.cpp Wed Jan 31 16:25:19 2018
@@ -868,10 +868,14 @@ bool MCAssembler::relaxLEB(MCAsmLayout &
   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();
 }
 

Added: llvm/trunk/test/MC/ELF/uleb-ehtable.s
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/MC/ELF/uleb-ehtable.s?rev=323934&view=auto
==============================================================================
--- llvm/trunk/test/MC/ELF/uleb-ehtable.s (added)
+++ llvm/trunk/test/MC/ELF/uleb-ehtable.s Wed Jan 31 16:25:19 2018
@@ -0,0 +1,28 @@
+// 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: )