-
Notifications
You must be signed in to change notification settings - Fork 694
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.
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 Module.customSections #877
Changes from 4 commits
bd1f38b
c10e7b4
94f3942
fea04e4
8dde47e
1ae783e
a441a8c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -174,7 +174,7 @@ The `exports` function has the signature: | |
Array exports(moduleObject) | ||
``` | ||
|
||
If `moduleObject` is not a `WebAssembly.Module` instance, a [`TypeError`](https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror) | ||
If `moduleObject` is not a `WebAssembly.Module`, a [`TypeError`](https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror) | ||
is thrown. | ||
|
||
This function returns an `Array` produced by mapping each | ||
|
@@ -193,7 +193,7 @@ The `imports` function has the signature: | |
Array imports(moduleObject) | ||
``` | ||
|
||
If `moduleObject` is not a `WebAssembly.Module` instance, a [`TypeError`](https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror) | ||
If `moduleObject` is not a `WebAssembly.Module`, a [`TypeError`](https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror) | ||
is thrown. | ||
|
||
This function returns an `Array` produced by mapping each | ||
|
@@ -205,6 +205,25 @@ to the Object `{ module: String(i.module_name), name: String(i.item_name), kind: | |
|
||
Note: other fields like `signature` may be added in the future. | ||
|
||
### `WebAssembly.Module.userSections` | ||
|
||
The `userSections` function has the signature: | ||
|
||
``` | ||
Array userSections(modueObject, sectionName) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Typo "modueObject". |
||
``` | ||
|
||
If `moduleObject` is not a `WebAssembly.Module`, a [`TypeError`](https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror) | ||
is thrown. | ||
|
||
Let `sectionNameString` be the result of [`ToString`](https://tc39.github.io/ecma262/#sec-tostring)(`sectionName`). | ||
|
||
This function returns an `Array` produced by mapping each | ||
[user-defined section](BinaryEncoding.md#high-level-structure) (i.e., section with | ||
`id` 0) whose `name` field ([decoded as UTF-8](Web.md#names)) is equal to | ||
`sectionNameString` to an `ArrayBuffer` containing the section's `payload_data`. | ||
(Note: `payload_data` does not include `name` or `name_len`.) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, technically There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was wondering about this. Why make a copy? Don't we have the original buffer copied already (to prevent user from modifying it while compiling)? Maybe not a big deal, but it seems wasteful when we could just provide a view over the existing copy. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we had the ability to return a read-only view, I'd do that, but otherwise we're in trouble if the user tries to write to the view. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, too bad. Though I suppose users who are concerned about this cost for very large modules can parse the module themselves. |
||
|
||
### Structured Clone of a `WebAssembly.Module` | ||
|
||
A `WebAssembly.Module` is a | ||
|
@@ -248,7 +267,7 @@ If the NewTarget is `undefined`, a [`TypeError`](https://tc39.github.io/ecma262/ | |
exception is thrown (i.e., this | ||
constructor cannot be called as a function without `new`). | ||
|
||
If `moduleObject` is not a `WebAssembly.Module` instance, a [`TypeError`](https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror) | ||
If `moduleObject` is not a `WebAssembly.Module`, a [`TypeError`](https://tc39.github.io/ecma262/#sec-native-error-types-used-in-this-standard-typeerror) | ||
is thrown. | ||
|
||
Let `module` be the [`Ast.module`](https://github.com/WebAssembly/spec/blob/master/interpreter/spec/ast.ml#L176) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We call them "unknown" sections in the binary format. I'd rather be consistent (either name is fine).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, I hadn't noticed; it seems we call them both "user-defined" and "unknown" sections. Seems like we should just go with one. I actually like "unknown" better than "user defined"; it contrasts better with "known". @rossberg-chromium ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I don't like the term "user". Seems condescending.
But "unknown" is weird.
So yeah, I don't care for either name ;-)
How about "named sections" everywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I have the same vague feeling re "user". I like "named".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We moved to calling these "user" sections in wabt, and in my proposed llvm binutils patch.
I think "user" is fine, and has more meaning than either "named" or "unkown" which don't seem to convey much to me. We're all used to "user_data" pointers in callbacks.