`--dir` does not work with non-absolute paths

[folkertdev]

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?

[bjorn3]

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.

[folkertdev]

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.

[alexcrichton]

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.

[folkertdev]

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.