cc @hoodmane

My understanding was that MAIN_MODULE=2 was not included for a reason there, but maybe I misunderstood something.

It was not included because it shouldn't be necessary. In the example:

em++ -g -sDISABLE_EXCEPTION_CATCHING=0 -s MAIN_MODULE=2 main_dlopen.cpp -sDYLINK_DEBUG=1 -o main_dlopen.js -sASSERTIONS=2 -sEXPORTED_FUNCTIONS=[_main] -sNO_AUTOLOAD_DYLIBS libside.wasm

The linker should look inside libside.wasm and see that it calls env.invoke_ji and then generate the appropriate wrappers. It seems like it doesn't do this correctly. So I think this is not the correct fix. OTOH it is an easy fix.

The example is only an easy reproducing case which exports everything (except the dynCalls)...

In reality the MAIN_MODULE has never seen the plugin before loading it. Hence it is hard (or even impossible) to pre-generate all dynCalls at compile time. From my point of view the only thing the main program really expects is that dlopen and dlsym work without side effects...

In reality the MAIN_MODULE has never seen the plugin before loading it

For that use case you're supposed to use -sMAIN_MODULE=1. For -sMAIN_MODULE=2 you are supposed to build all the side modules first and then include them as arguments when linking the main module. I think it's perfectly reasonable for the linker to check which day calls are used in the side module and include them.

That's a valid point.

If one is interpreting MAIN_MODULE=2 that way something to prevent the elimination of the call to createDyncallWrapper in dynCallLegacy would be super helpful.

@sbc100: Is there a way that doesn't need a new setting?

Yes I think we should be analyzing the side modules at link time and creating extra dynCalls accordingly.