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

Trying to run MIRI on MacOS #7936

Closed
rookieCookies opened this issue Feb 14, 2024 · 5 comments · Fixed by #7938
Closed

Trying to run MIRI on MacOS #7936

rookieCookies opened this issue Feb 14, 2024 · 5 comments · Fixed by #7938
Labels
bug Incorrect behavior in the current implementation that needs fixing

Comments

@rookieCookies
Copy link

Steps to Reproduce

  • Make a new cargo project
  • Add wasmtime = "*"
  • Do cargo miri run

Expected Results

Miri compiles and runs successfully

Actual Results

Failed to compile because of something inside the crate itself. I looked into the module traphandlers and sure enough there is no function named that

error[E0425]: cannot find function `using_mach_ports` in module `traphandlers`
  --> /Users/macbook/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmtime-runtime-17.0.1/src/traphandlers.rs:52:23
   |
52 |         traphandlers::using_mach_ports(),
   |                       ^^^^^^^^^^^^^^^^ not found in `traphandlers`

For more information about this error, try `rustc --explain E0425`.

Versions and Environment

Wasmtime version or commit: 17.0.1

Operating system: MacOS

Architecture: ARM

@rookieCookies rookieCookies added the bug Incorrect behavior in the current implementation that needs fixing label Feb 14, 2024
@bjorn3
Copy link
Contributor

bjorn3 commented Feb 14, 2024

Miri is unable to interpret jitted code, so even if this compile error is fixed, you still wouldn't be able to run wasm modules using wasmtime inside miri. It should be possible to compile wasm modules without actually running them though once this error is fixed.

alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Feb 14, 2024
@rookieCookies
Copy link
Author

It should be possible to compile wasm modules without actually running them though once this error is fixed.

Why? Can't it run in interpret-only mode?

@cfallin
Copy link
Member

cfallin commented Feb 14, 2024

Why? Can't it run in interpret-only mode?

Wasmtime doesn't have an interpreter tier, unfortunately; all Wasm execution depends on running native code generated by Cranelift.

@rookieCookies
Copy link
Author

Wasmtime doesn't have an interpreter tier, unfortunately; all Wasm execution depends on running native code generated by Cranelift.
Ahh, seriously? Bit unrelated to the PR but do you know of any way I can miri wasm?

@bjorn3
Copy link
Contributor

bjorn3 commented Feb 14, 2024

If you want to run miri on some code you want to compile to wasm, you did have to use cargo miri run --target wasm32-wasi instead of cargo run --target wasm32-wasi. Miri currently doesn't support wasi though afaik. You can't run miri on a wasm module. Miri can only run the MIR intermediate representation of rustc. After compilation to wasm only something like valgrind which uses dynamic instrumentation and heuristics about the source language is possible. It just so happens that wasmtime already has support for something like this behind the -W wmemcheck flag: https://github.com/bytecodealliance/wasmtime/blob/main/docs/wmemcheck.md You will need to recompile wasmtime with the wmemcheck cargo feature enable for this and as I said it uses heuristics and doesn't catch all UB something like miri would catch. For example violations of the stacked borrows rules or invalid values are not catched.

github-merge-queue bot pushed a commit that referenced this issue Feb 14, 2024
* Fix running MIRI tests on macOS

Closes #7936

* Fix unused function with miri
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect behavior in the current implementation that needs fixing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants