STANDALONE_WASM still imports some simple filesystem operations from "env"

[UnasZole]

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]

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.

[vadimkantorov]

It could be good to also have two options to shim out all WASI-undefined functions and to error out if a WASI-undefined function was used...