Add dynCall_sig adaptor for MAIN_MODULE == 2

[gl84]

Fixes #17707.

Follow up on PR #17328.

• Create the wasm adaptor also for MAIN_MODULE == 2
• Remove obsolete assert (triggers for all cases were we create the wrapper)

[kripken]

cc @hoodmane

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

[hoodmane]

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.

[gl84]

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

[hoodmane]

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.

[gl84]

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?

[sbc100]

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