Export mutable wasm globals as JS objects. NFC #25530
Conversation
sbc100
force-pushed
the
wasm_globals
branch
4 times, most recently
from
acef802 to
906bef0
Compare
| $isImmutableGlobal: (val) => { | ||
| if (val instanceof WebAssembly.Global) { | ||
| try { | ||
| val.value = val.value; |
There was a problem hiding this comment.
why this particular method of checking for the presence of the value property? Wouldn't it be easier to do hasOwnProperty or something?
There was a problem hiding this comment.
This check is only checking for mutability, which is not something that the JS spec exposes.
There was a problem hiding this comment.
Ah right. Since we expose immutable globals as numbers, should we have some kind of assertion that there aren't any immutable globals exported as wasm globals?
There was a problem hiding this comment.
Ah right. Since we expose immutable globals as numbers, should we have some kind of assertion that there aren't any immutable globals exported as wasm globals?
But we do have such exports. All data symbols (addresses) are exported in this way.
There was a problem hiding this comment.
Oh I guess you are saying, do we have tests that confirm if data exports are working? I assume we have many such tests.. basically any test that does EMSCRIPTEN_KEEPALIVE on a data symbol, or included a data symbols in EXPORTED_FUNCTIONS.
There was a problem hiding this comment.
More like, we expect everything exported as a WebAssembly.Global to be mutable (because up until now, all data exports are immutable and exported as numbers and we never exported anything as a mutable global other than the stack pointer). So if we ever see an immutable WebAssembly.Global it would be an error, right?
There was a problem hiding this comment.
Right, but this function (isImmutableGlobal) is used to disciminate bewtween those two types of exports.
Type 1: Mutable globals that we are exporting with the intent that they are exported as first class globals (e.g. __stack_pointer.
Type 2: Immutable globals that are exported as addresses, and are visible on the outside a simply numbers. These one also get relocated (+= __memory_base) so they can be used to index into the HEAP directly.
There was a problem hiding this comment.
i.e. at this point in the code we expect to see both types.
|
Remind me what the use you had in mind for this was? Just so users could export their own globals? |
My initial use case was to make exporting the But I can imagine we maybe have other mutable globals that also want to be import/exported between modules. |
For immutable wasm globals we currently export them as simple JS numbers at build time. This is because data symbol addresses are exported as immutable globals. However, its also useful to export real wasm globals. For now we treat mutable globals and immutable global differently here but we should look into perhaps changing that in the future.
2 participants
For immutable wasm globals we currently export them as simple JS numbers at build time. This is because data symbol addresses are exported as immutable globals.
However, its also useful to export real wasm globals. For now we treat mutable globals and immutable global differently here but we should look into perhaps changing that in the future.