You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using WAT as a first-class language, and have an issue resolving imports: If one module exports a value, and another module imports that value, there is no (clean) way for the host to resolve the import, unless it knows what the files contain in advance.
When using the JavaScript API (though this seems to apply generally), we use parseWat to parse the WAT source to a module, then use the module's toBinary method to compile the module to a buffer. The buffer is then passed to WebAssembly.instantiate (with a hash of imports), to get an instance (which exposes its exports as attributes).
The host must provide the imports to WebAssembly.instantiate, but has no obvious way of knowing what must be provided (the module and field names for each import).
The buffer has a log attribute which contains an import section with a subsection for each import. Parsing the log to extract each pair of module and field names is possible, but obviously pretty clunky. It's inherently unreliable too, as there's no formal grammar for the log, so the parsing is crude and would choke on more complex import strings.
Could we give the buffer (returned by toBinary) an imports attribute (as well as log) that references a hash of import strings (populated as the log is generated), using the module names as keys and the field names as values?
Thanks for considering this, and for all the hard work you do on the project (it's my first post here).
The text was updated successfully, but these errors were encountered:
Sorry I didn't respond to this, I was away on leave for the past 5 months!
It seems like this shouldn't be too difficult to do. By the time the wat has been parsed, all the information about the module is available. You should be able to add some functions to emscripten-helpers.cc to access the imports, add those functions to emscripten-exported.json, then reference those functions in wabt.post.js to access them in JavaScript.
I'd probably have a structure called WasmModuleImports that contains a vector of WasmImports. Then implement the following functions:
WasmModuleImports* wasm_module_get_imports(wabt::Module*);
int wasm_module_imports_get_length(WasmModuleImports*);
WasmImport* wasm_module_imports_get_import(WasmModuleImports*, int index);
const char* wasm_import_get_module_name(WasmImport*);
const char* wasm_import_get_field_name(WasmImport*);
I don't have time to work on something like this now, but maybe someone else does :)
I'm using WAT as a first-class language, and have an issue resolving imports: If one module exports a value, and another module imports that value, there is no (clean) way for the host to resolve the import, unless it knows what the files contain in advance.
When using the JavaScript API (though this seems to apply generally), we use
parseWat
to parse the WAT source to a module, then use the module'stoBinary
method to compile the module to a buffer. The buffer is then passed toWebAssembly.instantiate
(with a hash of imports), to get an instance (which exposes its exports as attributes).The host must provide the imports to
WebAssembly.instantiate
, but has no obvious way of knowing what must be provided (the module and field names for each import).The buffer has a
log
attribute which contains an import section with a subsection for each import. Parsing the log to extract each pair of module and field names is possible, but obviously pretty clunky. It's inherently unreliable too, as there's no formal grammar for the log, so the parsing is crude and would choke on more complex import strings.Could we give the buffer (returned by
toBinary
) animports
attribute (as well aslog
) that references a hash of import strings (populated as the log is generated), using the module names as keys and the field names as values?Thanks for considering this, and for all the hard work you do on the project (it's my first post here).
The text was updated successfully, but these errors were encountered: