Skip to content
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

STANDALONE_WASM still imports some simple filesystem operations from "env" #23008

Open
UnasZole opened this issue Nov 25, 2024 · 1 comment
Open

Comments

@UnasZole
Copy link

Hi,

I'm currently trying to build a command-line tool into WASM using emscripten.
The repository that builds this tool has a fairly complex build process (involving automake, libtool and hundreds of build steps), but thankfully it depends only on quite standard libraries, so thanks to Emscripten's support for zlib I managed to actually compile to WASM, and get a first version of the program running with emscripten's JS and HTML page. :-)

However, I was hoping to make it run as a standard WASI component to make it more portable.
Therefore I've tried the STANDALONE_WASM option as per the documentation (as well as a "PURE_WASI" option that I saw mentioned in tickets here, but seems to have no effect). And while the standalone WASM has fewer dependencies to the emscripten "env", it's still not, well, standalone.

Viewing the generated imports in wasm2wat, I see the following imports :

  (import "wasi_snapshot_preview1" "fd_close" (func $wasi_snapshot_preview1.fd_close (type $t0)))
  (import "wasi_snapshot_preview1" "fd_write" (func $wasi_snapshot_preview1.fd_write (type $t6)))
  (import "wasi_snapshot_preview1" "proc_exit" (func $wasi_snapshot_preview1.proc_exit (type $t3)))
  (import "wasi_snapshot_preview1" "fd_read" (func $wasi_snapshot_preview1.fd_read (type $t6)))
  (import "wasi_snapshot_preview1" "fd_seek" (func $wasi_snapshot_preview1.fd_seek (type $t50)))
  (import "wasi_snapshot_preview1" "environ_get" (func $wasi_snapshot_preview1.environ_get (type $t2)))
  (import "wasi_snapshot_preview1" "environ_sizes_get" (func $wasi_snapshot_preview1.environ_sizes_get (type $t2)))
  (import "env" "__syscall_faccessat" (func $env.__syscall_faccessat (type $t6)))
  (import "env" "__syscall_rmdir" (func $env.__syscall_rmdir (type $t0)))
  (import "env" "__syscall_unlinkat" (func $env.__syscall_unlinkat (type $t4)))
  (import "env" "__syscall_getdents64" (func $env.__syscall_getdents64 (type $t4)))
  (import "wasi_snapshot_preview1" "args_get" (func $wasi_snapshot_preview1.args_get (type $t2)))
  (import "wasi_snapshot_preview1" "args_sizes_get" (func $wasi_snapshot_preview1.args_sizes_get (type $t2)))

And as you can see, 4 filesystem calls remain untranslated to WASI : faccessat, rmdir, unlinkat, getdents64.
I know that some functionality of emscripten is not easily implemented in WASI (I've read thinks around exception management, etc.), but those seem to be fairly simple file system operations.
In particular, among those the WASI spec clearly specifies that the "path_remove_directory" is equivalent to POSIX unlinkat (cf. https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/docs.md#-path_remove_directoryfd-fd-path-string---result-errno ).

Is there any reason why these calls are not mapped to WASI in standalone mode ?

Here are my build details :

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.72 (437140d)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 1c4caece05f1885ba6ed80755d6b5de1b9f99579)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /emscripten/emsdk/upstream/bin

Linking command

libtool: link: /emscripten/emsdk/upstream/emscripten/em++ -Ofast -fPIC -DEXCLUDEBZIP2 -DEXCLUDEXZ -Wno-address -Wno-nonnull-compare -ftemplate-depth=100 -s USE_ZLIB=1 -s STANDALONE_WASM -s PURE_WASI -o osis2mod osis2mod.o  ../lib/.libs/libsword.a -lz

Thanks !

@kripken
Copy link
Member

kripken commented Dec 2, 2024

Looks like at least one of those would be fixed by #18285

It may be worth trying to get that PR landed, or at least parts of it. I'll comment there.

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

No branches or pull requests

2 participants