bors [Sun, 30 May 2021 15:14:23 +0000 (15:14 +0000)]
Auto merge of #1791 - Aaron1011:measureme, r=RalfJung
Add `measureme` integration for profiling the interpreted program
This PR uses the `measureme` crate to profile the call stack of the
program being interpreted by Miri. This is accomplished by starting a
measureme 'event' when we enter a function call, and ending the event
when we exit the call. The `measureme` tooling can be used to produce a
call stack from the generated profile data.
Limitations:
* We currently record every single entry/exit. This might generate very
large profile outputs for programs with a large number of function
calls. In follow-up work, we might want to explore sampling (e.g. only
recording every N function calls).
* This does not integrate very well with Miri's concurrency support.
Each event we record starts when we push a frame, and ends when we pop
a frame. As a result, the timing recorded for a particular frame will include all of the work Miri does before that frame completes, including executing another thread.
The `measureme` integration is off by default, and must be enabled via
`-Zmiri-measureme=<output_name>`
Aaron Hill [Sat, 8 May 2021 16:20:51 +0000 (12:20 -0400)]
Add `measureme` integration for profiling the interpreted program
This PR uses the `measureme` crate to profile the call stack of the
program being interpreted by Miri. This is accomplished by starting a
measureme 'event' when we enter a function call, and ending the event
when we exit the call. The `measureme` tooling can be used to produce a
call stack from the generated profile data.
Limitations:
* We currently record every single entry/exit. This might generate very
large profile outputs for programs with a large number of function
calls. In follow-up work, we might want to explore sampling (e.g. only
recording every N function calls).
* This does not integrate very well with Miri's concurrency support.
Each event we record starts when we push a frame, and ends when we pop
a frame. As a result, switching between virtual threads will cause
events from different threads to be interleaved. Additionally, the
recorded for a particular frame will include all of the work Miri does
before that frame completes, including executing another thread.
The `measureme` integration is off by default, and must be enabled via
`-Zmiri-measureme=<output_name>`
bors [Sat, 22 May 2021 12:56:51 +0000 (12:56 +0000)]
Auto merge of #1811 - RalfJung:less-rc, r=RalfJung
get rid of some `Rc`
Now that the memory access hooks get references to `MemoryExtra`, we can avoid refcounting for the global state of Stacked Borrows and the data race detector.
`@semarie` this should fix your problem... but I think any version of Miri actually shipped to users should have the proper git version information embedded, so I am not sure if this is the right fix. How do you do this for rustc proper? Even stable builds usually have a git version:
```
$ rustc +stable --version
rustc 1.51.0 (2fd73fabe 2021-03-23)
```
bors [Wed, 12 May 2021 14:57:42 +0000 (14:57 +0000)]
Auto merge of #1794 - cbeuw:83813, r=RalfJung
Sync with rustc_span changes
rust-lang/rust#83813 made some changes to SourceMap and RealFileName. Now to get a string from a `rustc_span::FileName`, we need to specify if we would like the local filesystem path or remapped path via `--remap-path-prefix`. There seems to be only one place in miri that requires change.
bors [Tue, 4 May 2021 08:27:00 +0000 (08:27 +0000)]
Auto merge of #1788 - hyd-dev:rustup, r=RalfJung
`encountered a NULL reference` -> `encountered a null reference`
It's changed from "NULL" to "null" (probably by rust-lang/rust#84842) in `rustc`, and causing some test failures:
https://github.com/rust-lang/miri/runs/2498333632#step:8:640
bors [Mon, 3 May 2021 17:32:50 +0000 (17:32 +0000)]
Auto merge of #1785 - Smittyvb:fast-math-ub, r=RalfJung
Throw UB if f*_fast intrinsic called with non-finite value
Calling these intrinsics with non-finite values is undefined behaviour, since they result in `f*` intrinsics in LLVM with the `fast` flag, and `fast` math on non-finite values results in `poison` values. (technically LLVM only considers it UB upon _using_ the value, but that shouldn't make much of a difference)
bors [Sat, 1 May 2021 16:07:48 +0000 (16:07 +0000)]
Auto merge of #1784 - hyd-dev:harness-false, r=RalfJung
Use `harness = false` instead of `#![feature(custom_test_frameworks)]`
Quoting from the comment in `tests/compiletest.rs`:
> Custom test runner, to avoid libtest being wrapped around compiletest which wraps libtest.
I believe `harness = false` is more suitable for that purpose.
I have verified that both `./miri test` and `LD_LIBRARY_PATH=$PWD/build/x86_64-unknown-linux-gnu/stage2/lib PATH=$PWD/build/bin:$PATH ./x.py test src/tools/miri` work well.
Auto merge of #1769 - RalfJung:remove-compat, r=oli-obk
remove compatibility code for passing miri flags via cargo arguments
With https://github.com/rust-lang/miri/pull/1540, we deprecated `cargo miri test -- -Zmiri-disable-stacked-borrows` as a style of passing flags to Miri, introducing `MIRIFLAGS="-Zmiri-disable-stacked-borrows" cargo miri test` instead. This made `cargo miri` more compatible with `cargo`; both now behave the same in terms of argument parsing.
However, to avoid breaking things, I introduced some backwards compatibility hack such that the old way would still work. Six months later, I think it is time to remove that hack.
projects / rust.git / log