From 45b12f18350ef5b73d77c71f9abcd7ed6ed57af8 Mon Sep 17 00:00:00 2001 From: Rafael Espindola Date: Thu, 1 Feb 2018 00:25:19 +0000 Subject: [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! llvm-svn: 323934 --- llvm/lib/MC/MCAssembler.cpp | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'llvm/lib') diff --git a/llvm/lib/MC/MCAssembler.cpp b/llvm/lib/MC/MCAssembler.cpp index bd881b4d6e8..a0f9a857e3c 100644 --- a/llvm/lib/MC/MCAssembler.cpp +++ b/llvm/lib/MC/MCAssembler.cpp @@ -868,10 +868,14 @@ bool MCAssembler::relaxLEB(MCAsmLayout &Layout, MCLEBFragment &LF) { 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(); } -- cgit v1.2.3