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.

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

WAT imports cannot be resolved dynamically. #1229

Open
carlsmith opened this issue Nov 17, 2019 · 1 comment
Open

WAT imports cannot be resolved dynamically. #1229

carlsmith opened this issue Nov 17, 2019 · 1 comment

Comments

@carlsmith
Copy link

carlsmith commented Nov 17, 2019

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).

@binji
Copy link
Member

binji commented Jan 10, 2020

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants