mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update README for some tracing being available on nightlies

Browse Source
This commit is contained in:
Ralf Jung 2018-12-23 14:21:15 +01:00
parent 4f659ed507
commit d8c9c9dd4f
1 changed files with 24 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
README.md
View File

@ -90,7 +90,7 @@ things (like adding support for a new intrinsic) can be done by working just on
the miri side.
To prepare, make sure you are using a nightly Rust compiler. You also need to
set up a libstd that enables execution with miri:
set up a libstd that enables execution with Miri:
```sh
rustup override set nightly # or the nightly in `rust-version`
@ -98,7 +98,7 @@ cargo run --bin cargo-miri -- miri setup
```
The last command should end in printing the directory where the libstd was
built. Set that as your MIRI_SYSROOT environment variable:
built. Set that as your `MIRI_SYSROOT` environment variable:
```sh
export MIRI_SYSROOT=~/.cache/miri/HOST # or whatever the previous command said
@ -109,7 +109,7 @@ export MIRI_SYSROOT=~/.cache/miri/HOST # or whatever the previous command said
Now you can run Miri directly, without going through `cargo miri`:
```sh
cargo run tests/run-pass-fullmir/format.rs # or whatever test you like
cargo run tests/run-pass/format.rs # or whatever test you like
```
You can also run the test suite with `cargo test --release`. `cargo test
@ -120,14 +120,33 @@ less time.
Now you are set up! You can write a failing test case, and tweak miri until it
fails no more.
You can get a trace of which MIR statements are being executed by setting the
`MIRI_LOG` environment variable. For example:
```sh
MIRI_LOG=info cargo run tests/run-pass/vecs.rs
```
Setting `MIRI_LOG` like this will configure logging for miri itself as well as
the `rustc::mir::interpret` and `rustc_mir::interpret` modules in rustc. You
can also do more targeted configuration, e.g. to debug the stacked borrows
implementation:
```sh
MIRI_LOG=rustc_mir::interpret=info,miri::stacked_borrows cargo run tests/run-pass/vecs.rs
```
In addition, you can set `MIRI_BACKTRACE=1` to get a backtrace of where an
evaluation error was originally created.
### Using a locally built rustc
Since the heart of Miri (the main interpreter engine) lives in rustc, working on
Miri will often require using a locally built rustc. The bug you want to fix
may actually be on the rustc side, or you just need to get more detailed trace
of the execution -- in both cases, you should develop miri against a rustc you
compiled yourself, with debug assertions (and hence tracing) enabled.
of the execution than what is possible with release builds -- in both cases, you
should develop miri against a rustc you compiled yourself, with debug assertions
(and hence tracing) enabled.
The setup for a local rustc works as follows:
```sh
@ -149,22 +168,6 @@ rustup override set custom
With this, you should now have a working development setup! See
["Testing Miri"](#testing-miri) above for how to proceed.
Moreover, you can now run Miri with a trace of all execution steps:
```sh
MIRI_LOG=debug cargo run tests/run-pass/vecs.rs
```
Setting `MIRI_LOG` like this will configure logging for miri itself as well as
the `rustc::mir::interpret` and `rustc_mir::interpret` modules in rustc. You
can also do more targeted configuration, e.g. to debug the stacked borrows
implementation:
```sh
MIRI_LOG=rustc_mir::interpret=debug,miri::stacked_borrows cargo run tests/run-pass/vecs.rs
```
In addition, you can set `MIRI_BACKTRACE=1` to get a backtrace of where an
evaluation error was originally created.
### Miri `-Z` flags and environment variables
Several `-Z` flags are relevant for Miri: