blob: 90bf739c17d0402dccd28ea178eea8b343b44332 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
;; NOTE: Assertions have been generated by update_lit_checks.py and should not be edited.
;; RUN: wasm-opt %s -g -o %s.wasm -osm %s.wasm.map
;; RUN: wasm-opt %s.wasm -ism %s.wasm.map -S -o - | filecheck %s
;; Verify that writing to a source map and reading it back does not "smear"
;; debug info across adjacent instructions. The debug info in the output should
;; be identical to the input.
(module
;; CHECK: (func $test (param $0 i32) (result i32)
;; CHECK-NEXT: (drop
;; CHECK-NEXT: (call $test
;; CHECK-NEXT: ;;@ waka:100:1
;; CHECK-NEXT: (i32.const 1)
;; CHECK-NEXT: )
;; CHECK-NEXT: )
;; CHECK-NEXT: ;;@ waka:200:2
;; CHECK-NEXT: (i32.const 2)
;; CHECK-NEXT: )
(func $test (param i32) (result i32)
;; The drop&call have no debug info, and should remain so. Specifically the
;; instruction right before them in the binary (the const 1) should not
;; smear its debug info on it. And the drop is between an instruction that
;; has debug info (the const 1) and another (the i32.const 2): we should not
;; receive the debug info of either. (This is a regression test for a bug
;; that only happens in that state: removing the debug info either before or
;; after would avoid that bug.)
(drop
(call $test
;;@ waka:100:1
(i32.const 1)
)
)
;;@ waka:200:2
(i32.const 2)
)
;; CHECK: (func $same-later (param $0 i32) (result i32)
;; CHECK-NEXT: (drop
;; CHECK-NEXT: (call $test
;; CHECK-NEXT: ;;@ waka:100:1
;; CHECK-NEXT: (i32.const 1)
;; CHECK-NEXT: )
;; CHECK-NEXT: )
;; CHECK-NEXT: ;;@ waka:100:1
;; CHECK-NEXT: (i32.const 2)
;; CHECK-NEXT: )
(func $same-later (param i32) (result i32)
;; As the first, but now the later debug info is also 100:1. No debug info
;; should change here.
(drop
(call $test
;;@ waka:100:1
(i32.const 1)
)
)
;;@ waka:100:1
(i32.const 2)
)
;; CHECK: (func $more-before (param $0 i32) (result i32)
;; CHECK-NEXT: ;;@ waka:50:5
;; CHECK-NEXT: (nop)
;; CHECK-NEXT: ;;@ waka:50:5
;; CHECK-NEXT: (drop
;; CHECK-NEXT: (call $test
;; CHECK-NEXT: ;;@ waka:100:1
;; CHECK-NEXT: (i32.const 1)
;; CHECK-NEXT: )
;; CHECK-NEXT: )
;; CHECK-NEXT: ;;@ waka:200:2
;; CHECK-NEXT: (i32.const 2)
;; CHECK-NEXT: )
(func $more-before (param i32) (result i32)
;; As the first, but now there is more debug info before the 100:1 (the
;; very first debug info in a function has special handling, so we test it
;; more carefully).
;;
;; The s-parser actually smears 50:5 on the drop and call after it, so the
;; output here looks incorrect. This may be a bug there, TODO
;;@ waka:50:5
(nop)
(drop
(call $test
;;@ waka:100:1
(i32.const 1)
)
)
;;@ waka:200:2
(i32.const 2)
)
;; CHECK: (func $nothing-before (param $0 i32) (result i32)
;; CHECK-NEXT: (nop)
;; CHECK-NEXT: (drop
;; CHECK-NEXT: (call $test
;; CHECK-NEXT: ;;@ waka:100:1
;; CHECK-NEXT: (i32.const 1)
;; CHECK-NEXT: )
;; CHECK-NEXT: )
;; CHECK-NEXT: ;;@ waka:200:2
;; CHECK-NEXT: (i32.const 2)
;; CHECK-NEXT: )
(func $nothing-before (param i32) (result i32)
;; As before, but no debug info on the nop before us (so the first
;; instruction in the function no longer has a debug annotation). Nothing
;; should change in the debug info.
(nop)
(drop
(call $test
;;@ waka:100:1
(i32.const 1)
)
)
;;@ waka:200:2
(i32.const 2)
)
)
|
