Can't pass 64-bit pointers from native code to native code through JS

[TheComputerGuy96]

Version of emscripten/emsdk:
emscripten 5.0.4 "emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 5.0.4 (62e22652509fbe7a00609ce48a653d0d66f27ba5)"

Code sample (compile with emcc and -sMEMORY64=1):

#include <emscripten.h>
#include <stdint.h>
#include <stdio.h>

void EMSCRIPTEN_KEEPALIVE frog(uint32_t *toad) {
    printf("Pointer contents: %d\n", *toad);
}

int main(void) {
    uint32_t tadpole = 42;

    EM_ASM("_frog($0);", &tadpole);

    return 0;
}

This should print Pointer contents: 42 (while with -sMEMORY64=1 option, this causes a TypeError: Cannot convert <number> to a BigInt error)

The problematic piece of code is here: https://github.com/emscripten-core/emscripten/blob/5.0.5/src/parseTools.mjs#L478 (which is still present in commit a7804ea)

This notably affects miniaudio in 64-bit mode (the audio output is silent; there's no issue tracked for that bug yet though)

[sbc100]

Yes, unfortunately seamless support for wasm64 pointers (and pointer-sized things like size_t) still sometimes requires some manual intervention. We really should have better docs on this.

In emscripten we try to auto-convert all pointers to Number at the JS boundary. For calling from JS into wasm this means you may need to tell emscripten about which exported function take pointers. In this case the solution is to add your exported function to the SIGNATURE_CONVERSIONS setting: https://emscripten.org/docs/tools_reference/settings_reference.html#signature-conversions`.

e.g. -sSIGNATURE_CONVERSIONS=frog:vp

This tells emscripten the signature of the frog function so it can create the correct wrapper (in this case v means returns void and p mean the first arg is a pointer).

Alternatively, you could also modify your EM_ASM to cast to BigInt when needed. e.g.

EM_ASM("
#ifdef __wasm64__
_frog(BigInt($0));
#else
_frog($0);
#endif
", &tadpole);

[TheComputerGuy96]

e.g. -sSIGNATURE_CONVERSIONS=frog:vp

That isn't really viable in Miniaudio (which is a header-only library) unless all the build systems/users add it to their compile arguments (I may not be aware of some pragma though)

Alternatively, you could also modify your EM_ASM to cast to BigInt when needed

Wouldn't that codepath still fundamentally truncate the pointer arguments though?

I personally did a uintptr cast for the pointer arguments in Miniaudio (which bypasses the broken codepath and makes passing arguments work without errors): TheComputerGuy96/miniaudio@00c4ab4

[sbc100]

Wouldn't that codepath still fundamentally truncate the pointer arguments though?

It essentially limits pointer to i53 rather then i64, which in practice is more than enough address space since its more than the e.g. x86_64 which only has a 48-bit address space.

That alternative to using number is that we could let BitInt values flow though the JS code, but we discovered that that was ever more intrusive since you cannot so basic JS arithmatic between BitInt and Number values, so it would break any code that did ptr += 4 or ptr == 0 from JS.