wasm2c is hardcoded to depend on dynCall_xx exports from native code

[sbc100]

As of #12059 we are moving away form the native dynCall functions but because of wasm2c's dependency we currently use the legacy mode when WASM2C is enabled.

Instead it should use direct wasm table access in all cases (unlike JS which still needs to use dynCalls for i64 signatures if WASM_BIGINT is missing).

Do wew enable WASM_BIGINT when WASM2C is enabled? Perhaps we should.

See #12002

[kripken]

I don't think WASM_BIGINT makes a difference here. The issue is that if the program uses exceptions or longjmp, it needs invokes and dynCalls, one per signature basically, and it assumes those are in the wasm.

When #12059 lands I can debug this, but I assume we just need to teach the output to call the wasm2c-emitted Table directly, instead of a dynCall export.

[sbc100]

I don't think WASM_BIGINT makes a difference here. The issue is that if the program uses exceptions or longjmp, it needs invokes and dynCalls, one per signature basically, and it assumes those are in the wasm.

When #12059 lands I can debug this, but I assume we just need to teach the output to call the wasm2c-emitted Table directly, instead of a dynCall export.

Yes, exactly.

I guess what I mean is, with wasm2c we don't want binaryen to generate any dyncCalls, not even i64 once, because we can't call the i64 ones direclty.

So the code the tells binaryen to generate the dynCalls should do the same thing that the WASM_BIGINT=1 path does... which makes me thing make all the places we check for bigint support would want to return true on wasm2c, right?

[kripken]

@sbc100 Oh right, now I understand. Makes sense, I opened #12069