Skip to content

Commit d1bd4a4

Browse files
authored
Specify display conventions for wasm locations (#1053)
Applies especially for use on the web, but useful for consistency in tools and other cases as well.
1 parent 89cfa62 commit d1bd4a4

File tree

1 file changed

+66
-0
lines changed

1 file changed

+66
-0
lines changed

Web.md

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -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

129195
WebAssembly's [modules](Modules.md) allow for natural [integration with

0 commit comments

Comments
 (0)