function signature mismatch when building with WASM_BIGINT

[Mintyboi]

I have a sample app that results in a function signature mismatch when I build the side module with -s WASM_BIGINT=1. My app runs fine if the side module is not built with -s WASM_BIGINT=1.

Unfortunately I have not done much debugging into this at the moment.
I was thinking if anyone can help to point me to where I can start looking into.
Meanwhile I'll step through the wasm code from the chrome dev console to see if I can find anything.

A reproducer can be found here:
funcSigMismatch.zip

These are the command I used to build the app:
side module: emcc side.cpp -Oz -s SIDE_MODULE=2 --profiling -flto -fPIC -s WASM_BIGINT=1 -o side.wasm
main module emcc main.cpp -Oz -s MAIN_MODULE=2 --profiling -s WASM_BIGINT=1 --pre-js preload.js -flto -fPIC --profiling -s EXPORTED_FUNCTIONS=['_main','__Znwm','__ZTI4Base','__ZTVN10__cxxabiv120__si_class_type_infoE'] -o index.js

[Mintyboi]

@sbc100 I found the issue, somewhat.
When we load a side module and inside postInstantiation(), we initialize the global ctors via the exported __post_instantiate function.

emscripten/src/library_dylink.js

Line 515 in 5ea9517

var init = moduleExports['__post_instantiate'];

This is fine when the side module is built without -s WASM_BIGINT=1, because we export the wasm_call_ctors with

(export "__post_instantiate" (func $__wasm_call_ctors))

However, when the side module is built with -s WASM_BIGINT=1, the wasm_call_ctors is exported as

(export "__wasm_call_ctors" (func $__wasm_call_ctors))

[kripken]

I can't think of how WASM_BIGINT would change an export, so that's odd.

Are there other exports? You may see something like (export "__post_instantiate" (func $__wasm_call_ctors)) - an export name with a different function name - if the functions were identical and merged by the optimizer. The internal name can change, but the export name should not.

To investigate this you can look at the output from LLVM (using EMCC_DEBUG=1 to save all temp files during link). That is completely unaffected by WASM_BIGINT. Then see what changes binaryen does in the later files.

[sbc100]

Ah! This must be because this renaming is done by binaryen and when WASM_BIGINT=1 we are skipping wasm-emscripten-finalize. That makes sense now. Thanks for tracking it down!

[kripken]

Oh wow, good catch...

[Mintyboi]

Thanks for the quick response and fixes!