-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
stage2: Add limited WASI support for selfExePath and globalCacheDir #11024
Conversation
The other nice thing about WASI is it's not too hard to emulate a subset of it in browsers |
fec1f3b
to
b60f2bb
Compare
I've hit what seems to be an instability in the CI tests a couple times now, related to the test "POSIX file locking with fcntl". Maybe the 1ms wait in that test is too low? Is this a known problem? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit to reorder sentence and question on tests with recommended preopen
Chose to make this dependent on #11053 - Let's try to get that one merged first |
This change adds support for locating the Zig executable and the library and global cache directories, based on looking in the fixed "/zig" and "/cache" directories. Since our argv[0] on WASI is just the basename (any absolute/relative path information is deleted by the runtime), there's very limited introspection we can do on WASI, so we rely on these fixed directories. These can be provided on the command-line using `--mapdir`, as follows: ``` wasmtime --mapdir=/cwd::. --mapdir=/cache::"$HOME/.cache/zig" --mapdir=/zig::./zig-out/ ./zig-out/bin/zig.wasm ```
I tried making a build, but it seems to be broken now.
|
Dependent on #11053. Resolves #10716.
This PR adds support for locating the Zig executable and the library and global cache directories, based on looking in the fixed "/zig" and "/cache" directories. It also bypasses the file-locking in "src/Cache.zig" and initializes the WASI preopens on startup.
The expected directories can be provided on the command-line using
--mapdir
, as follows:The reason for the fixed directories is that argv[0] on WASI is just the basename (any absolute/relative path information is deleted by the runtime) and there is no WASI-equivalent to procfs.
This is enough to get stage2 running without LLVM on WASI:
This should be considered highly experimental - I haven't even checked the behavior tests or anything.