Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add suggested format for wasm frames in Error.stack #814

Closed
wants to merge 3 commits into from
Closed

Add suggested format for wasm frames in Error.stack #814

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
19b8573
Add Error.stack SHOULD clause
Oct 3, 2016
85ea06d
Mention Names section for function names
Oct 4, 2016
de99b42
Change offset to best-effort
Oct 4, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions JS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,21 @@ Because JavaScript exceptions can be handled, and JavaScript can continue to
call WebAssembly exports after a trap has been handled, traps do not, in
general, prevent future execution.

Even though the `stack` property of JS `Error` objects is not specified by
ES-262, implementations *should* include WebAssembly stack frames in
the generated callstacks. [User-defined sections](BinaryEncoding.md#high-level-structure)
may arbitrarily affect the displayed stack frames. However, by default, when
no relevant sections are present:
* The line number reported for a WebAssembly frame *should* be the offset of the
the trap/call instruction within the module's originally-compiled binary.
* The column number reported for WebAssembly frames, if not omitted entirely,
*should* be 1.
* The function name *should* be generated from the template string literal
`wasm-function[${i}]` where `i` is the index of the function in the module's
[Code section](BinaryEncoding.md#code-section).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasm-function is the symbol section?

"or $i if no symbol section is present"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not quite: I'm saying that if you have a stack frame which you'd print as foo@url:line:col (if it was JS) and if you have no Names section (so you don't have any "foo"), that a function name would be generated, with strawman "wasm-function[0]" (where "0" is the index of the function).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah gotcha. Why not have wasm-function at all then, and not just $i?

Also: I'm not sure I understand where you mention the Names section. Could you say:

The function name should be generated from a module's Names section if present, otherwise the string literal $i should be used where i is the index of the function in the module's Code section.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention was just to be able to syntactically distinguish the wasm functions from the normal JS functions since you'll see them mixed into the same callstack. I did indeed forget to explicitly mention the Names section here; I'll add that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, update looks good.

* The filename *should* be that of the JS caller of the originating `Module`
constructor call.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not the .wasm file if there was one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only JS APIs we have atm take an ArrayBuffer of bytes so I think this is the best we can do. With ES6 module integration, we could have the same URLs as JS <script>s. With Streams integration, if you WebAssembly.compile(stream), maybe we could use the URL that was fetched to produce stream.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, right.


## The `WebAssembly` object

The `WebAssembly` object is the initial value of the `WebAssembly` property of
Expand Down