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

[Ryan Prichard via llvm-commits]

On Tue, Jan 30, 2018 at 6:51 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> 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?
>

I think both the "0000:" and the ")" lines can be changed to CHECK-NEXT. I
can make those changes.

> +  // 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.
>

That makes sense. I'll take out the LEB "relax allowances" behavior.

I'm not sure whether to update uleb-optimal.s with a padded LEB or remove
it. I think I'm inclined to remove it. It doesn't test anything that
uleb-ehtable.s doesn't test, and it would fail on previous LLVM assemblers
without indicating a bug in them.

Thanks,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180130/fa9d1991/attachment.html>