8000 Emscripten: Add wasm64 target by ktock · Pull Request #927 · libffi/libffi · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Emscripten: Add wasm64 target #927

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Conversation

ktock
Copy link
@ktock ktock commented Jun 27, 2025

This PR adds support for building libffi with Emscripten's -sMEMORY64 flag.

A new wasm64 target is introduced in the build scripts. When this is selected, the -sMEMORY64=1 flag is automatically passed to emcc, enabling 64bit addressing.

autoreconf -fiv
emconfigure ./configure --host=wasm64-unknown-linux --prefix="$TARGET" --enable-static --disable-shared --disable-dependency-tracking \
  --disable-builddir --disable-multi-os-directory --disable-raw-api --disable-docs
make install

Emscripten's -sMEMORY64 has another mode (-sMEMORY64=2) which allows the 64bit code to run on wasm32 engines. To enable this mode, WASM64_MEMORY64 variable can be used.

autoreconf -fiv
emconfigure ./configure --host=wasm64-unknown-linux --prefix="$TARGET" --enable-static --disable-shared --disable-dependency-tracking \
  --disable-builddir --disable-multi-os-directory --disable-raw-api --disable-docs WASM64_MEMORY64=2
make install

ktock added 5 commits June 27, 2025 17:49
MEMORY64 enables 64bit pointers so this commit updates the accessors for the
libffi data structures accordingly.

Each JS functions in ffi.c receives pointers as BigInt (i64) values and with
casts them to Numer (i53) using bigintToI53Checked. While memory64 supports
64bit addressing, the maximum memory size is currently limited to 16GiB
[1]. Therefore, we can assume that the passed pointers are within the
Number's range.

[1] https://webassembly.github.io/memory64/js-api/#limits

Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
This commit adds support for the wasm64 target via the configure
script. Emscripten supports two modes of the -sMEMORY64 flag[1] so the
script allows users specifying the value through a configuration variable.

Additionally, "src/wasm32" directory has been renamed to the more generic
"src/wasm" because it's now shared between both 32bit and 64bit builds.

[1] https://emscripten.org/docs/tools_reference/settings_reference.html#memory64

Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
This commit adds a test matrix for wasm32, wasm64 and wasm64 with the
-sMEMORY64=2 flag, using the latest version of Emscripten. -Wno-main is
added to suppress the following warning in unwindtest.cc and
unwindtest_ffi_call.cc.

> FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -O2 (test for excess errors)
> Excess errors:
> ./libffi.closures/unwindtest_ffi_call.cc:20:5: warning: 'main' should not be 'extern "C"' [-Wmain]
>    20 | int main (void)
>       |     ^
> 1 warning generated.

Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
test_libffi.py calls each test's main function without arguments, but some
tests define the main function with parameters. This signature mismatch
causes a runtime error with the recent version of Emscripten.

This commit resolves this issue by updating the function signatures to match
the way they are called.

Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Copy link
Contributor
@kleisauke kleisauke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! In Emscripten, we usually use #ifdef __wasm64__ and #ifdef __wasm32__ for these checks, but I like this approach as well.

It also makes me wonder if we could rely more on the __SIZEOF_*__ macros instead of using hardcoded values (and perhaps use something like #define FFI_ALIGNOF(type) _Alignof(type)?), but that be done as a possible follow-up.

@hoodmane Would you like to review this as well?

@ktock
Copy link
Author
ktock commented Jul 8, 2025

Thank you for your review, @kleisauke !

Can we move this forward? cc @hoodmane @atgreen

Comment on lines +68 to +69
# TODO: node-based tests of wasm64 requires newer version of node (v23.0.0)
# which isn't available on the current emsdk.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use an action to install node 24?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't use the node from emsdk anyways.

@@ -123,6 +123,8 @@ AC_C_BIGENDIAN

GCC_AS_CFI_PSEUDO_OP

AC_ARG_VAR([WASM64_MEMORY64], [Used only for the wasm64 target. Set to 1 (default) or 2 for Emscripten's -sMEMORY64 mode])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between these?

var struct_arg_info = [];
for (var i = nargs - 1; i >= nfixedargs; i--) {
var arg_ptr = DEREF_U32(avalue, i);
var arg_unboxed = unbox_small_structs(DEREF_U32(arg_types_ptr, i));
var arg_ptr = DEC_PTR(DEREF_PTR(avalue, i));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could use a macro for DEC_PTR(DEREF_PTR(x))?

@hoodmane
Copy link
Contributor
hoodmane commented Jul 8, 2025

Code looks good to me. In a few places the formatting could be improved, and it might be nice to add more macros for common patterns. But I would be fine with merging as-is as well, other than adding a test with node 24.

7384

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0