WebAssembly.LinkError caused by enabling ALLOW_TABLE_GROWTH without RESERVED_FUNCTION_POINTERS

[AlexAltea]

Commit b472d78 introduced ALLOW_TABLE_GROWTH, which is extremely useful when it comes to dynamic linking and JIT-compiling modules, e.g. #7082 (comment).

With the latest incoming revision, it seems that ALLOW_TABLE_GROWTH requires a non-zero value in RESERVED_FUNCTION_POINTERS. This seems counter-intuitive to me: Unlike in asm.js, we should have no need to reserve in advance a fixed array of function pointers.

Example:

$ cat demo.c
#include <stdio.h>
int main() { printf("Hello!\n"); return 0; }

$ emcc demo.c -s ALLOW_TABLE_GROWTH=1 -s RESERVED_FUNCTION_POINTERS=1 -o demo.js && node demo.js
Hello!

$ emcc demo.c -s ALLOW_TABLE_GROWTH=1 -s RESERVED_FUNCTION_POINTERS=0 -o demo.js && node demo.js
failed to asynchronously prepare wasm: LinkError: WebAssembly Instantiation: table import 21 has no maximum length, expected 10
[...]

$ emcc demo.c -s ALLOW_TABLE_GROWTH=1 -o demo.js && node demo.js
failed to asynchronously prepare wasm: LinkError: WebAssembly Instantiation: table import 21 has no maximum length, expected 10
[...]

[kripken]

I think the problem here is that with asm2wasm we don't know the size of the function table, not until asm2wasm happens, which is after we emit the JS.

This is not a problem with the LLVM wasm backend, so going forward this will go away anyhow. You may want to already use it now, btw, if it fixes this issue for you - it's getting close to being the default anyhow.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.