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: unassignedb...@nondot.org
Reporter: ryan.prich...@gmail.com
CC: llvm-bugs@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
