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

[Rafael Avila de Espindola via llvm-commits]

Ryan Prichard via Phabricator via llvm-commits
<llvm-commits at lists.llvm.org> writes:

> +// ELF:   Name: .data
> +// MACHO: Name: __data
> +// CHECK: SectionData (
> +// CHECK:   0000: 112233FF 7FCDCDCD CDCDCDCD CDCDCDCD
> +// CHECK:   4000: CDCD0000 01020304
> +// CHECK: )

CHECK-NEXT maybe?

> +// ELF:   Name: .data
> +// MACHO: Name: __data
> +// CHECK: SectionData (
> +// CHECK:   0000: FF01FFFF 00CDCDCD CDCDCDCD CDCDCDCD
> +// CHECK:   4000: CDCDCDCD 01020304
> +// CHECK: )

CHECK-NEXT maybe?

> Index: lib/MC/MCAssembler.cpp
> ===================================================================
> --- lib/MC/MCAssembler.cpp
> +++ lib/MC/MCAssembler.cpp
> @@ -869,10 +869,21 @@
>    Data.clear();
>    raw_svector_ostream OSE(Data);
>    if (LF.isSigned())
> -    encodeSLEB128(Value, OSE);
> +    encodeSLEB128(Value, OSE, LF.getPadLEBTo());
>    else
> -    encodeULEB128(Value, OSE);
> -  return OldSize != LF.getContents().size();
> +    encodeULEB128(Value, OSE, LF.getPadLEBTo());
> +  uint64_t NewSize = LF.getContents().size();
> +
> +  // Sometimes the compiler generates 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. Allow an LEB fragment's size to
> +  // shrink a few times, then prevent it from further shrinking. See PR35809.

This is not LEB specific. A branch getting bigger can put another branch
in range for a smaller encoding. If we are to support this it should be
a general property of the relaxation loop.

I would suggest leaving this out of the initial fix.

Cheers,
Rafael