@@ -124,6 +124,72 @@ MIME type mismatch or `opaque` response types
124
124
[ reject] ( http://tc39.github.io/ecma262/#sec-rejectpromise ) the Promise with a
125
125
` WebAssembly.CompileError ` .
126
126
127
+ ## Developer-facing display conventions
128
+
129
+ Browsers, JavaScript engines, and offline tools have common ways of referring to
130
+ JavaScript artifacts and language constructs. For example, locations in
131
+ JavaScript source code are printed in stack traces or error messages, and are
132
+ represented naturally as decimal-format lines and columns in text files. Names
133
+ of functions and variables are taken directly from the sources. Therefore (for
134
+ example) even though the exact format of Error.stack strings does not always
135
+ match, the locations are easily understandable and the same across browsers.
136
+
137
+ To achive the same goal of a common representations for WebAssembly constructs, the
138
+ following conventions are adopted.
139
+
140
+ A WebAssembly location is a reference to a particular instruction in the binary, and may be
141
+ displayed by a browser or engine in similar contexts as JavaScript source locations.
142
+ It has the following format:
143
+
144
+ ` ${url}:wasm-function[${funcIndex}]:${pcOffset} `
145
+
146
+ Where
147
+ * ` ${url} ` is the URL associated with the module, if applicable (see notes).
148
+ * ` ${funcIndex} ` is an index in the [ function index space] ( Modules.md#function-index-space ) .
149
+ * ` ${pcOffset} ` is the offset in the module binary of the first byte
150
+ of the instruction, printed in hexadecimal with lower-case digits,
151
+ with a leading ` 0x ` prefix.
152
+
153
+ Notes:
154
+ * The URL field may be interpreted differently depending on the
155
+ context. When the response-based
156
+ instantiation [ API] ( #additional-web-embedding-api ) is used in a
157
+ browser, the associated URL should be used; or when the
158
+ ArrayBuffer-based instantiation
159
+ [ API] ( JS.md#webassemblyinstantiate ) is used, the browser should represent
160
+ the location of the API call. This kind of instantiation is analagous to
161
+ executing JavaScript using ` eval ` ; therefore if the browser has an existing
162
+ method to represent the location of the ` eval ` call it can use a similar
163
+ one for ` WebAssembly.instantiate ` . For example if the browser uses
164
+ ` foo.js line 10 > eval ` or ` eval at bar (foo.js:10:3) ` for ` eval ` , it could
165
+ use ` foo.js line 10 > WebAssembly.instantiate ` or
166
+ ` WebAssembly.instantiate at bar (foo.js:10:3) ` , respectively.
167
+ Offline tools may use a filename instead.
168
+ * Using hexadecimal for module offsets matches common conventions in native tools
169
+ such as objdump (where addresses are printed in hex) and makes them visually
170
+ distinct from JavaScript line numbers. Other numbers are represented in decimal.
171
+
172
+ While the ` name ` property of [ exported WebAssembly functions] ( JS.md#exported-function-exotic-objects )
173
+ is specified by the JS API, synthesized function names are also
174
+ displayed in other contexts like devtool callstacks and ` Error.stack ` .
175
+ If a WebAssembly module contains a [ "name" section] ( BinaryEncoding.md#name-section ) ,
176
+ these names should be used to synthesize a function name as follows:
177
+ * If a function name subsection is present, the displayed name should
178
+ be ` ${module_name}.${function_name} ` or ` ${function_name} ` , depending
179
+ on whether the module name is present.
180
+ * Otherwise, the output can be context-dependent:
181
+ * If the function name is shown alongside its location in a
182
+ stack trace, then just the module name (if present) or an empty string
183
+ can be used (because the function index is already in the location).
184
+ * Otherwise, ` ${module_name}.wasm-function[${funcIndex}] ` or
185
+ ` wasm-function[${funcIndex}] ` should be used to convey the function index.
186
+
187
+ Note that this document does not specify the full format of strings such as
188
+ stack frame representations; this allows engines to continue using their
189
+ existing formats for JavaScript (which existing code may already be depending
190
+ on) while still printing WebAssembly frames in a format consistent with
191
+ JavaScript.
192
+
127
193
## Modules
128
194
129
195
WebAssembly's [ modules] ( Modules.md ) allow for natural [ integration with
0 commit comments