-s MAIN_MODULE=1 + upstream + function pointer calls using i64 => TypeError: cannot pass i64 to or from JS

[gl84]

Hi everybody! I'm starting to learn emscripten and ran in the following problem when reading from a preloaded file (input.txt)

#include <cstdio>

int main() {
    FILE* file_ = std::fopen("input.txt","rb");
    printf("file pointer %p\n",(void*)file_);
    if (file_) {
        std::fseek(file_, 0l, SEEK_END);
        std::fclose(file_);
    }
    return 0;
}

when using
emcc main.cpp -g -s MAIN_MODULE=1 --preload-file input.txt -o main.html -s EXPORTED_FUNCTIONS=['_main']

on the latest upstream version (atm 1.38.46 (commit 41adfea)).

The runtime error on fseek in firefox is

exception thrown: TypeError: cannot pass i64 to or from JS,@http://0.0.0.0:8002/main.js line 1015 > WebAssembly.Module:wasm-function[0]:0x0
__fseeko_unlocked@http://0.0.0.0:8002/main.js line 2316 > WebAssembly.instantiate:wasm-function[1072]:0x33216
__fseeko@http://0.0.0.0:8002/main.js line 2316 > WebAssembly.instantiate:wasm-function[1073]:0x3324f
fseek@http://0.0.0.0:8002/main.js line 2316 > WebAssembly.instantiate:wasm-function[1074]:0x3327f
__original_main@http://0.0.0.0:8002/main.js line 2316 > WebAssembly.instantiate:wasm-function[163]:0x6dec
main@http://0.0.0.0:8002/main.js line 2316 > WebAssembly.instantiate:wasm-function[164]:0x6e19
Module._main@http://0.0.0.0:8002/main.js:40295:32
callMain@http://0.0.0.0:8002/main.js:49234:22
doRun@http://0.0.0.0:8002/main.js:49294:23
run/<@http://0.0.0.0:8002/main.js:49305:7

In Chromium I get a similar TypeError...

Compiling with -s MAIN_MODULE=0
emcc main.cpp -g -s MAIN_MODULE=0 --preload-file input.txt -o main.html -s EXPORTED_FUNCTIONS=['_main']
works as expected.

Anybody any ideas?

Thanks!

[kripken]

Thanks @gl84! I see this problem too on your testcase (I had to create input.txt and fill it with arbitrary data).

What seems to happen here is that we reach code like

Module['_fp$__stdio_seek$jiji'] = function() {
  
  assert(Module["___stdio_seek"] || typeof ___stdio_seek !== "undefined", "external function `__stdio_seek` is missing.perhaps a side module was not linked in? if this symbol was expected to arrive from a system library, try to build the MAIN_MODULE with EMCC_FORCE_STDLIBS=XX in the environment");
  var func = Module['___stdio_seek'];
  if (!func)
    func = ___stdio_seek;
  var fp = addFunction(func, 'jiji');
  Module['_fp$__stdio_seek$jiji'] = function() { return fp };
  return fp;
}

This ends up adding a JS function to the table. But the problem seems to be that we even reach this code, since __stdio_seek is part of libc... it should be linked in to the main module.

@sbc100 any idea what's going on there?

[jeromelaban]

I have another test case that seems similar, again with -s MAIN_MODULE=1:

#include <stdio.h>

long long testAdd(int a, int b)
{
    return a+b;
}

typedef long long (*testAddHandler)(int, int);

int main()
{
    testAddHandler h = &testAdd;
    long long r = h(42, 42);

    printf("Result: %d\n", r);
}

Edit: Built with emcc myfile.cpp -s MAIN_MODULE=1

All methods seem to be added to the JS function table even if they're not exported (not sure if the JS table is an actual export though, thinking out of my way there 😊), and indirect calls seem to go through JS, and fail when an i64 is used.

[jeromelaban]

@sbc100 is there something I could do to help for that issue ?

[gl84]

@jeromelaban
I played a bit with your testcase and found that in your case a call_indirect throws.

As the return type in the call_indirect is in both cases i64 I suppose that means that either

• the table is broken or
• the used index into the table is wrong.

[jeromelaban]

What I'm finding curious is that the indirect call to testhandler is redirected through javascript, and some generated and injected wasm module, and the parameters are passed through there.

Then javascript magic fails because of the i64 return value. This does not happen when dynamic linking is not enabled.

[kripken]

Thanks @jeromelaban, yeah, the redirection through JS does sound like the issue.

@sbc100 I think I have an idea about how to fix this, given that. Would you mind if I take a look, or are you working on it?

[sbc100]

I'm not looking at this right now no. I am curious though how this managed to fall through the cracks.. don't we test filesystem + MAIN_MODULE?

[kripken]

Cool, I'll look into it then. My theory is that it's related to MAIN_MODULE + function pointers + i64 parameters, specifically where the addFunction code which generates a wasm module on the fly before adding to the table. I think that's not working right and using JS somehow.

[kripken]

Ok, there look to be several issues here. Together, they cause any i64-using function pointer call to fail on the upstream backend with MAIN_MODULE. So this is a much more serious issue than just the filesystem (as @jeromelaban's last testcase shows).

• create_fp_accessors in emscripten.py handles the fp$ prefixed functions, implementing them by adding to the table. It adds Module.X or X (from JS global scope).
• That may not be the wasm function, but a JS wrapper around it (which we create for async compilation, or for assertion checks). So we need to skip that wrapper by looking at Module.asm.X to get the actual export from wasm. This removes the involvement of JS here, which is the first problem.
• However, that isn't enough, as we have legalized the wasm exports for JS's sake. So that wasm export has i32, i32 as params instead of an i64, etc. So the indirect call in the wasm has the wrong type.

One possible solution is for the legalization pass to also export the original illegal-for-JS function, if it is illegal. Maybe X and X$byn-original or such. Then we can use that one if necessary (we do know the type, so it's easy to do).

Does that make sense @sbc100 ?

[sbc100]

It seems like a good idea to export the original functions for cases when they can be used directly by other wasm modules like this yes.

How about orig$<name>. Or maybe we should do it the other way around and export js$<name> functions when we fix the functions?

[kripken]

I think orig$<name> is good. The other way would be a breaking change, as the common case is where an export is called from JS, and so must be legalized. It's rare for JS to want to access the actual illegal function (which we only need here as the dynamic linking loader is in JS, for now).