dlopen() documentation is wrong, and related issue should not be closed

[mewalig]

In particular, from https://emscripten.org/docs/compiling/Dynamic-Linking.html?highlight=dlopen:

Runtime dynamic linking can be performed by the calling the dlopen() function ... That’s basically it - you can then use dlopen(), dlsym(), etc. normally. (emphasis mine)

The second part of that statement is 100% false

Issue #11753 still exists.

Could the documentation please be corrected, and issue #11753 re-opened until a solution has been put into place?

[sbc100]

Indeed that documentation does look incorrect. The ability to use dlopen does depend on the module being pre-loading (does preloading work for you BTW?), or using ASYNCIFY to be able to suspend the execution of the main thread.

I recently added the emscripten_dlopen function that allows a cooperative way to do an async module load (#14503), and that should be added to this documentation too.

[mewalig]

Unfortunately, the solution, as far as I understand, that involves preloading will not work for our purposes. If it were only a matter of requiring preloading, then we could at least partly achieve our goal (generally, preloading is undesirable because we want the wasm code to behave the same as it would as a desktop app, and for the desktop app we allow users to bring-your-own-shared-lib-extension so that they can plug their custom routines into the framework-- but this isn't as critical for a wasm version, since the BYO aspect is less likely to be used)

But the other part of that solution-- correct me if I'm wrong-- requires that the extension functions are called via Javascript code. In our case, the extension might provide a function that gets called inside a loop that executes 1 million times over the course of a few seconds, and which needs to be passed pointers to shared memory, and it would not be feasible or desirable for each iteration of the loop to leave the C code just to get into Javascript to then make the callback to the extension, which normally the C code would just directly call via the pointer returned by dlsym. Technically I suppose we could stitch all of that together, but it would require adding a significant amount of otherwise unnecessary code-- and even then I am not sure the result would be feasible from a performance perspective.

I don't suppose that there is any easy way to provide some modified form of dlopen which would be akin to "dlopen_memory" and that operated directly on a single chunk of memory that holds the entire extension? That would seem to address the async problem, though I have no idea what other issues it may introduce.

[sbc100]

The async problem is due to the instantiation of the module itself. Having that module in memory or on disk doesn't effect that. One still needs to instantiate the module to get an instance.

I'm not sure what you mean by "functions are called via Javascript code". If you use dlsym you will get a pointer which will call directly into the side module mode. The return value of dlsym is an integer which, like all function pointers in WebAssembly, is an index into the call_indirect table and the table slot will contain that Wasm function from the side module. It should be basically identical to calling any other function pointer.

[mewalig]

OK, maybe I misunderstood one of the last comments in #11753:

As you can see from my code, I'm currently using Module[['_side']] () to call the function from a loaded side module and this way seems to work fine.

But if I try to call this function using dlsym and RTLD_DEFAULT, it was not able to call the function.

I guess the above was referring only to a situation without preloading, whereas everything works fine with preloading? If so, then to use preloading, does that mean that i) side.wasm must be named side.so and ii) side.so must already exist in the emscripten file system prior to instantiating main.wasm? Or will side.wasm get fetched automatically without having to manually load it into the emscripten FS?

[sbc100]

i) It looks like if you want to use the preloadPlugins mechanism then yes you need to call the files .so. The code for the preload plugin is here

emscripten/src/library_browser.js

Lines 244 to 250 in 5ebe1d4

	// Use string keys here to avoid minification since the plugin consumer
	// also uses string keys.
	var wasmPlugin = {
	'asyncWasmLoadPromise': new Promise(function(resolve, reject) { return resolve(); }),
	'canHandle': function(name) {
	return !Module.noWasmDecoding && name.endsWith('.so')
	},

.
ii) If you want to use the preload plugins you pass --preload-file to emcc. Doing this will make the file appear in the fileystem, and also means that any preload plugins will run on that file prior to starting your program.

However, if you just want the modules to be loaded and available before your program starts then the simplest way these day is probably just to pass the name of the side modules on the command line when linking the main module. Doing this will add those libraries to Module[' dynamicLibraries'] automatically, which will mean they will get loaded before your program starts. Any symbols from your side module will be available directly and (I think) also indirectly if you do dlopen('side.so') + dlsym without any blocking or loading (since that part will have been done already).

[mewalig]

Will try, thank you. Is it expected that the .so file is very large. and/or would you have any recommendations to safely strip? Comparing the two:

Standalone + extension compiled together into a single executable: 4MB
Standalone: 3MB
Extension: 11MB

All compiled with -O3 -s FORCE_FILESYSTEM=1, and the extension also with -s SIDE_MODULE=1 (but not EXPORT_ALL). Am also using -flto in case that matters

(By contrast, compiling to native (non-wasm) code on osx, the standalone with extension compiled into a single executable is 3MB, and the extension is 5MB, but compiled without any particular stripping)

[sbc100]

If you want to shrink the size of your SIDE_MODULE you can build with SIDE_MODULE=2 and explictly specify the list of symbols you need using EXPORTED_FUNCTIONS=foo,bar. Building with SIDE_MODULE (AKA SIDE_MODULE=1) assumes that all symbols are needed and exported.

[sbc100]

You can also use tools such as https://github.com/google/bloaty to see what symbols are taking up space in your resulting binary.