[llvm-bugs] [Bug 35809] New: Assembler runs forever trying to assemble file with uleb128 and balign

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35809

            Bug ID: 35809
           Summary: Assembler runs forever trying to assemble file with
                    uleb128 and balign
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: ryan.prichard at gmail.com
                CC: llvm-bugs at lists.llvm.org

The LLVM MC assembler loops forever trying to assemble this:

            .data
            .uleb128 thing_end - thing
    thing:
            .byte 0xd1, 0xd2, 0xd3, 0xd4
            .balign 2
            .fill 0x7b, 1, 0xcc
    thing_end:

It's not obvious how to assemble it, because it's impossible to satisfy all the
apparent constraints:

 - If the .uleb128 is only one byte [encodes 00..0x7f], then .balign 2 also
uses one byte, and (thing_end - thing) is 0x80.

 - If the .uleb128 is two bytes, then .balign 2 (should?) use zero bytes, and
(thing_end - thing) is 0x7f. 0x7f's uleb128 encoding is one byte.

I don't know if this issue is a practical concern yet. I noticed it while
looking at Clang's DWARF EH output, which uses udata4 encoding for offsets
rather than uleb128.

The GNU assembler successfully assembles it by expanding .balign 2 into two
zero bytes, which surprised me, because the directive was already aligned to 2
bytes.

    $ gcc uleb128-assembly-problem.s -c && readelf -x .data
uleb128-assembly-problem.o
    Hex dump of section '.data':
      0x00000000 8101d1d2 d3d40000 cccccccc cccccccc ................
      0x00000010 cccccccc cccccccc cccccccc cccccccc ................
      0x00000020 cccccccc cccccccc cccccccc cccccccc ................
      0x00000030 cccccccc cccccccc cccccccc cccccccc ................
      0x00000040 cccccccc cccccccc cccccccc cccccccc ................
      0x00000050 cccccccc cccccccc cccccccc cccccccc ................
      0x00000060 cccccccc cccccccc cccccccc cccccccc ................
      0x00000070 cccccccc cccccccc cccccccc cccccccc ................
      0x00000080 cccccc                              ...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180103/a1c48076/attachment.html>