[llvm-bugs] [Bug 44807] New: llvm-objdump cannot understand symbols emitted by wasm reference toolchain
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Feb 5 16:51:01 PST 2020
https://bugs.llvm.org/show_bug.cgi?id=44807
Bug ID: 44807
Summary: llvm-objdump cannot understand symbols emitted by wasm
reference toolchain
Product: tools
Version: 10.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: llvm-objdump
Assignee: unassignedbugs at nondot.org
Reporter: ggreif at gmail.com
CC: llvm-bugs at lists.llvm.org
I am at 10.0.0-rc1.
Wasm reference toolchain is here:
https://github.com/WebAssembly/spec/blob/master/interpreter/binary/encode.ml#L459
`llvm-objdump` calls `onSymbolStart` and probably fails. Caller doesn't check
return code.
Something gets disassembled, but neither symbol names appear, nor " .local".
here is what is dumped:
Disassembly of section CODE:
00000000 CODE:
# 210 functions in section.
2: 8c f32.neg
3: 80 i64.div_u
4: 80 i64.div_u
5: 80 i64.div_u
6: 00
7: 00
8: 20 00 local.get 0
a: 41 03 i32.const 3
c: 6a i32.add
d: 41 04 i32.const 4
f: 6e i32.div_u
10: 10 53 call 83
12: 0b end
13: a0 f64.add
14: 80 i64.div_u
15: 80 i64.div_u
16: 80 i64.div_u
17: 00
18: 00
19: 23 00 global.get 0
1b: 41 7f i32.const -1
1d: 6a i32.add
1e: 20 00 local.get 0
20: 41 04 i32.const 4
22: 6c i32.mul
23: ad i64.extend_i32_u
24: 23 01 global.get 1
26: 7c i64.add
27: 24 01 global.set 1
29: 23 00 global.get 0
2b: 20 00 local.get 0
2d: 41 04 i32.const 4
2f: 6c i32.mul
30: 6a i32.add
31: 24 00 global.set 0
33: 23 00 global.get 0
35: 10 54 call 84
37: 0b end
38: aa i32.trunc_f64_s
39: 80 i64.div_u
3a: 80 i64.div_u
3b: 80 i64.div_u
3c: 00
3d: 01 nop
3e: 01 nop
3f: 7f i64.div_s
40: 20 00 local.get 0
42: 41 80 80 04 i32.const 65536
46: 6e i32.div_u
47: 41 01 i32.const 1
49: 6a i32.add
4a: 3f 00 memory.size 0
4c: 6b i32.sub
4d: 22 01 local.tee 1
4f: 41 00 i32.const 0
51: 4a i32.gt_s
52: 04 40 if
54: 20 01 local.get 1
56: 40 00 memory.grow 0
58: 41 00 i32.const 0
5a: 48 i32.lt_s
5b: 04 40 if
5d: 41 ff ff 03 i32.const 65535
61: 10 55 call 85
63: 00
64: 0b end
65: 0b end
66: 0b end
As you can see the `wasm` suite doesn't use shortest uleb128 encoding for the
symbol size. This is because the bytes get backpatched on emission when the
full buffer is already built. This is why the uleb128 size is 5 bytes for the
symbol size.
Maybe I am completely wrong, I cannot put my finger onto a sleb128 decoder bug
after cursory inspection.
Here is the binary dump of the section head:
Contents of section CODE:
0000 d2018c80 80800000 20004103 6a41046e ........ .A.jA.n
0010 10530ba0 80808000 00230041 7f6a2000 .S.......#.A.j .
0020 41046cad 23017c24 01230020 0041046c A.l.#.|$.#. .A.l
0030 6a240023 0010540b aa808080 0001017f j$.#..T.........
0040 20004180 80046e41 016a3f00 6b220141 .A...nA.j?.k".A
0050 004a0440 20014000 41004804 4041ffff .J.@ . at .A.H.@A..
0060 03105500 0b0b0b8e 80808000 00200041 ..U.......... .A
0070 096a2000 28020510 0e0b8980 80800000 .j .(...........
0080 419b8004 1055000b 89808080 00002000 A....U........ .
0090 20011003 000ba680 80800001 017f4104 .............A.
00a0 10532202 41073602 01200241 00360205 .S".A.6.. .A.6..
00b0 20024101 36020920 02200136 020d2002 .A.6.. . .6.. .
00c0 0ba68080 80000101 7f410410 53220241 .........A..S".A
00d0 07360201 20024101 36020520 02410136 .6.. .A.6.. .A.6
00e0 02092002 20013602 0d20020b a6808080 .. . .6.. ......
00f0 0001017f 41041053 22024107 36020120 ....A..S".A.6..
0100 02410236 02052002 41013602 09200220 .A.6.. .A.6.. .
0110 0136020d 20020ba6 80808000 01017f41 .6.. ..........A
0120 04105322 02410736 02012002 41033602 ..S".A.6.. .A.6.
0130 05200241 01360209 20022001 36020d20 . .A.6.. . .6..
0140 020ba680 80800001 017f4104 10532202 ..........A..S".
0150 41073602 01200241 04360205 20024101 A.6.. .A.6.. .A.
0160 36020920 02200136 020d2002 0ba68080 6.. . .6.. .....
0170 80000101 7f410410 53220241 07360201 .....A..S".A.6..
0180 20024106 36020520 02410136 02092002 .A.6.. .A.6.. .
0190 20013602 0d20020b a6808080 0001017f .6.. ..........
01a0 41041053 22024107 36020120 02410836 A..S".A.6.. .A.6
...
--
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/20200206/922fd216/attachment-0001.html>
More information about the llvm-bugs
mailing list