Force everything from a --js-library to be included in imports.

[cyraid]

Edit: In the end I used .net wasi-wasm output, unbundled the component model wasm, and loaded the webassembly in the browser manually by stubbing out the wasi preview1 and preview2 (implementing some bare minimum ones for now). It's a good start, but you gotta do what you gotta do sometimes.

Hi there,

Because I'm having a js file available for multiple wasm files, but using a single js file, is there a way to always include every function from that js library? Currently they get stripped out with dead code elimination.

I've tried DEFAULT_LIBRARY_FUNCS_TO_INCLUDE to include them, and they do include the functions as _func, but don't include them in the import list. To save me from manually adding every single file manually, is there an option to just include everything in the --js-library to imports?

[sbc100]

You could try -sEXPORT_ALL which exports all the JS library function to the outside world (this also prevents DCE).

Can you explain what you mean by "a js file available for multiple wasm files". If you are trying to take the generated JS file for one wasm and use it with another, that is not something is supported by emscripten today. The generated JS file bakes in a bunch of assumptions about the specific wasm file it wa built for.

We have had plans in the past to allow this but it won't work today.

[cyraid]

Not to bump this, but yeah, would be nice to be able to 'force' adding to wasmImports (like a, "it's up to you, okay then" kinda deal).

[cyraid]

Well, I have an API and dynamic set of wasm files, each compiled with the same emscripten setup (compiler arguments). I don't want the JavaScript to tampered with by users, but only the wasm files to be interchanged (they will be provided by users). The user compiles their wasm with an editor, using the same emscripten arguments in such in the end, but they only send the .wasm file that the browser runs.

So the only thing with the .wasm files change is which imports they call, and they may not use every single api import.

Using DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[func1,func2] "works", but I still have to manually change the js afterwards to include the function in the imports list manually, func1: _func1, etc.

I suppose (based on your response) there's no way to turn off DCE for a specific js-library ?

[cyraid]

I mean, what's the point of wasi then? It's an API. You guys support that? I may just have to go down the wasmer ask road and load wasi compatible wasm files instead of emscripten.

[kleisauke]

FWIW, you could avoid DCE by doing this inside the library file:

addToLibrary({
  $my_js: function() {
    console.log('hi');
  },
});
// Or: `DEFAULT_LIBRARY_FUNCS_TO_INCLUDE.push('$my_js');` prior to Emscripten 3.1.47.
extraLibraryFuncs.push('$my_js');

A possible way to modify the import list is to override the Module.instantiateWasm = function(imports, successCallback) callback. This gives you full control to instantiate the Wasm module manually and define any additional imports you need. See for example:

emscripten/test/test_manual_wasm_instantiate.html

Lines 168 to 186 in fcb4648

	Module.instantiateWasm = (imports, successCallback) => {
	console.log('instantiateWasm: instantiating asynchronously');
	wasm.then((bytes) => {
	console.log('wasm download finished, begin instantiating');
	var wasmInstantiate = WebAssembly.instantiate(bytes, imports).then((output) => {
	// When overriding instantiateWasm, in asan builds, we also need
	// to take care of creating the WasmOffsetConverter
	if (typeof WasmOffsetConverter != "undefined") {
	wasmOffsetConverter = new WasmOffsetConverter(bytes, output.module);
	}
	console.log('wasm instantiation succeeded');
	Module.testWasmInstantiationSucceeded = 1;
	successCallback(output.instance);
	}).catch((e) => {
	console.log('wasm instantiation failed! ' + e);
	});
	});
	return {}; // Compiling asynchronously, no exports.
	}

[sbc100]

The JS code generated by emscripten never designed to run anything other than the single program it was built for. If you would like to make a feature request for some kind of generic universal JS loader that would be reasonable, its juts not something that exists today.

[sbc100]

// Or: DEFAULT_LIBRARY_FUNCS_TO_INCLUDE.push('$my_js'); prior to Emscripten 3.1.47.
extraLibraryFuncs.push('$my_js')

IIRC these method only cause the functions to be included in the initial generated JS file. These do not prevent later optimizations from removing them as unused/dead (assume there are no users).

[cyraid]

Thanks for the replies guys. Unfortunately even when I tried manual instantiation, the imports passed were only {env: {}, wasip_preview: {}} (I'm reciting it from memory and on mobile, but it was empty with two categories in it.

If I'm gonna make a generator of some kind, I might as well go the generating a wit file and do the wasi approach. I might get some luck with wasmer sdk, or maybe even making my own universal JavaScript access.

Unless someone has some other ideas. Thanks for at least trying to think of something. :)