Stream: git-wasmtime

Topic: wasmtime / issue #10490 `--dir` does not work with non-ab...

Wasmtime GitHub notifications bot (Mar 30 2025 at 12:14):

folkertdev added the bug label to Issue #10490.

Wasmtime GitHub notifications bot (Mar 30 2025 at 12:14):

folkertdev opened issue #10490:

I'm trying to write a runner in .cargo/config.toml that passes a subdirectory to wasmtime. I'd like that path to be relative, so it works anywhere, not just on my machine. However, I can't get this to work:

[target.wasm32-wasip2]
runner = "wasmtime --dir ./my-subdir"

this command works on the command line (but won't in the cargo/config.toml because the $PWD variable is not expanded)

wasmtime --dir "$PWD/test-libz-rs-sys" target/wasm32-wasip2/debug/deps/test_libz_rs_sys-b4a8595daba8c0ca.wasm

but this does not

wasmtime --dir "./test-libz-rs-sys" target/wasm32-wasip2/debug/deps/test_libz_rs_sys-b4a8595daba8c0ca.wasm

nor does this

wasmtime --dir "test-libz-rs-sys" target/wasm32-wasip2/debug/deps/test_libz_rs_sys-b4a8595daba8c0ca.wasm

I've seen that just "." is accepted, so I'm confused why "./test-libz-rs-sys" does not work. It would be really convenient if the path is expanded (though maybe there are security issues that I'm overlooking?). In any case the current behavior is unexpected (to me).

Versions and Environment

Wasmtime version or commit: wasmtime 31.0.0 (7a9be587f 2025-03-20)

Operating system: linux

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 30 2025 at 13:41):

bjorn3 commented on issue #10490:

The matching of open calls to pre-opened directories happens inside wasi-libc, not inside wasmtime: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/sources/preopens.c Additionally wasi doesn't have any concept of a current working directory, so if you have a pre-opened directory with a relative path, you can only access it from the wasm module by using a relative path when opening.

Wasmtime GitHub notifications bot (Mar 30 2025 at 14:07):

folkertdev commented on issue #10490:

Ok, knowing a bit more about the internal implementation makes the current behavior make more sense. In hindsight the documentation also says that, but that's not what I read before.

So then, should a runner like in my example work somehow (idk, with a new flag that expands the path)? In our case we need that because we use a rust workspace, and hence need to open paths relative to CARGO_MANIFEST_DIR.

Wasmtime GitHub notifications bot (Mar 31 2025 at 18:33):

alexcrichton commented on issue #10490:

Under the hood here the basic idea is that a host path is presented to the guest under some name. The guest is then responsible for translating all of its path accesses as relative to whatever has been provided. The meaning of --dir foo means that the host directory "foo" is presented to the guest as "foo" as well. You can also pass --dir foo::bar though to use the host directory "foo" but the guest directory "bar". I realize though I might also be reiterating things you already know here.

What it means for your runner though sort of depends, but my guess is that there's probably not a great answer at this time. Ideally what would happen is you would interpose yourself when passing paths to the guest so the guest would open a wasm-specific path. It looks like you're "just" running cargo test though and that's what's not working, and in such a situation there's not much recourse for changing wasm's understanding of CARGO_MANIFEST_DIR, a compile-time variable.

In lieu of that though one thing I do is I typically have --dir . set in my runner command-line. It's a bad approximation of sorts but it gets cargo test working mostly so long as you don't use absolute paths.

Wasmtime GitHub notifications bot (Mar 31 2025 at 18:39):

folkertdev closed issue #10490:

I'm trying to write a runner in .cargo/config.toml that passes a subdirectory to wasmtime. I'd like that path to be relative, so it works anywhere, not just on my machine. However, I can't get this to work:

[target.wasm32-wasip2]
runner = "wasmtime --dir ./my-subdir"

this command works on the command line (but won't in the cargo/config.toml because the $PWD variable is not expanded)

wasmtime --dir "$PWD/test-libz-rs-sys" target/wasm32-wasip2/debug/deps/test_libz_rs_sys-b4a8595daba8c0ca.wasm

but this does not

wasmtime --dir "./test-libz-rs-sys" target/wasm32-wasip2/debug/deps/test_libz_rs_sys-b4a8595daba8c0ca.wasm

nor does this

wasmtime --dir "test-libz-rs-sys" target/wasm32-wasip2/debug/deps/test_libz_rs_sys-b4a8595daba8c0ca.wasm

I've seen that just "." is accepted, so I'm confused why "./test-libz-rs-sys" does not work. It would be really convenient if the path is expanded (though maybe there are security issues that I'm overlooking?). In any case the current behavior is unexpected (to me).

Versions and Environment

Wasmtime version or commit: wasmtime 31.0.0 (7a9be587f 2025-03-20)

Operating system: linux

Architecture: x86_64

Extra Info

Anything else you'd like to add?

Wasmtime GitHub notifications bot (Mar 31 2025 at 18:39):

folkertdev commented on issue #10490:

Yeah the part I was missing is that it's the literal string that gets mapped, not some understanding of the file system.

Well, we've hardcoded the path for github CI now, that will have to do.

Last updated: Apr 18 2025 at 12:05 UTC