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>`
add empty line before backtrace, to separate it from help text
I think this improves how things look, and makes it easier to see the help text (it currently kind of drowns next to the backtrace).
Before:
```
error: unsupported operation: Miri does not support threading
--> /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
|
68 | let ret = libc::pthread_create(&mut native, &attr, thread_start, &*p as *const _ as *mut _);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Miri does not support threading
|
= help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
= note: inside `std::sys::unix:🧵:Thread::new` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
= note: inside `std:🧵:Builder::spawn_unchecked::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:492:26
= note: inside `std:🧵:Builder::spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:386:18
= note: inside `std:🧵:spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:619:5
note: inside `main` at tests/compile-fail/thread-spawn.rs:6:5
--> tests/compile-fail/thread-spawn.rs:6:5
|
6 | thread::spawn(|| {});
| ^^^^^^^^^^^^^^^^^^^^
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:34
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:73
= note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<[closure@DefId(1:6030 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]::{{closure}}[0]) 0:&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys_common/backtrace.rs:130:5
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:13
= note: inside `std::panicking::try::do_call::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:331:40
= note: inside `std::panicking::try::<i32, [closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe]>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:274:15
= note: inside `std::panic::catch_unwind::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panic.rs:394:14
= note: inside `std::rt::lang_start_internal` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:51:25
= note: inside `std::rt::lang_start::<()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:5
```
After:
```
error: unsupported operation: Miri does not support threading
--> /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
|
68 | let ret = libc::pthread_create(&mut native, &attr, thread_start, &*p as *const _ as *mut _);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Miri does not support threading
|
= help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
= note: inside `std::sys::unix:🧵:Thread::new` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
= note: inside `std:🧵:Builder::spawn_unchecked::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:492:26
= note: inside `std:🧵:Builder::spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:386:18
= note: inside `std:🧵:spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:619:5
note: inside `main` at tests/compile-fail/thread-spawn.rs:6:5
--> tests/compile-fail/thread-spawn.rs:6:5
|
6 | thread::spawn(|| {});
| ^^^^^^^^^^^^^^^^^^^^
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:34
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:73
= note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<[closure@DefId(1:6030 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]::{{closure}}[0]) 0:&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys_common/backtrace.rs:130:5
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:13
= note: inside `std::panicking::try::do_call::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:331:40
= note: inside `std::panicking::try::<i32, [closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe]>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:274:15
= note: inside `std::panic::catch_unwind::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panic.rs:394:14
= note: inside `std::rt::lang_start_internal` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:51:25
= note: inside `std::rt::lang_start::<()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:5
```
What do you think?
env shim: make sure we clean up all the memory we allocate
`Machine` memory is not leak-checked, so if we forgot to deallocate part of the env shim memory, we wouldn't even notice. Thus add a dedicated memory kind that is leak-checked.
Abort instead of panic on asserting intrinsics
This fixes#1222
replacing the panic with an abort and a corresponding message.
the stack trace is already printed, this just adds an optional message the caller can pass, and I just pass the same message we passed to the panic but now to the abort instead.
r? @RalfJung
