@@ -124,6 +124,72 @@ MIME type mismatch or `opaque` response types
124124[ reject] ( http://tc39.github.io/ecma262/#sec-rejectpromise ) the Promise with a
125125` WebAssembly.CompileError ` .
126126
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+
127193## Modules
128194
129195WebAssembly's [ modules] ( Modules.md ) allow for natural [ integration with
0 commit comments