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>`
1. The double quotes around <untagged> are changed to backspaces, so <untagged>
will render correctly in markdown.
2. Clarify that -Zmiri-track-raw-pointers will never accept code that Miri
would not have accepted without -Zmiri-track-raw-pointers.
Add an `fn_ptr` field to `MiriFrame`
The `backtrace-rs` crate can use this to implement
`Frame::symbol_address`, which is used to skip frames
above the call to `Backtrace::capture` on the stack.
The function pointer will not be useable for comparison purposes if the
function is generic, as CTFE creates a new function pointer for each
cast of a (monomorphized) generic function. However, this already
affects code running under Miri, and isn't a problem for `backtrace-rs`
(which only casts a non-generic function).
I've added logic to allow `MiriFrame` to have either 4 or 5 fields - if
a 5th field is present, we write the function pointer to it.
The `backtrace-rs` crate can use this to implement
`Frame::symbol_address`, which is used to skip frames
above the call to `Backtrace::capture` on the stack.
The function pointer will not be useable for comparison purposes if the
function is generic, as CTFE creates a new function pointer for each
cast of a (monomorphized) generic function. However, this already
affects code running under Miri, and isn't a problem for `backtrace-rs`
(which only casts a non-generic function).
I've added logic to allow `MiriFrame` to have either 4 or 5 fields - if
a 5th field is present, we write the function pointer to it.
This PR adds two new Miri-defined extern functions:
`miri_get_backtrace` and `miri_resolve_frame`, which are documented in
the README. Together, they allow obtaining a backtrace for the currently
executing program.
I've added a test showing how these APIs are used. I've also prepared a
companion PR `backtrace-rs`, which will allow
`backtrace::Backtrace::new()` to work automatically under Miri.
Once these two PRs are merged, we will be able to print backtraces from
the normal Rust panic hook (since libstd is now using backtrace-rs).
A few notes:
* Resolving the backtrace frames is *very* slow - you can actually see
each line being printed out one at a time. Some local testing showed
that this is not (primrary) caused by resolving a `Span` - it seems
to be just Miri being slow.
* For the first time, we now interact directly with a user-defined
struct (instead of just executing the user-provided MIR that
manipulates the struct). To allow for future changes, I've added
a 'version' parameter (currently required to be 0). This should allow
us to change the `MiriFrame` struct should the need ever arise.
* I used the approach suggested by @oli-obk - a returned backtrace
pointer consists of a base function allocation, with the 'offset'
used to encode the `Span.lo`. This allows losslessly reconstructing
the location information in `miri_resolve_frame`.
* There are a few quirks on the `backtrace-rs` side:
* `backtrace-rs` calls `getcwd()` by default to try to simplify
the filename. This results in an isolation error by default,
which could be annoying when printing a backtrace from libstd.
* `backtrace-rs` tries to remove 'internal' frames (everything between
the call to `Backtrace::new()` and the internal API call made by
backtrace-rs) by comparing the returned frame pointer value to
a Rust function pointer. This doesn't work due to the way we
construct the frame pointers passed to the caller. We could
attempt to support this kind of comparison, or just add a
`#[cfg(miri)]` and ignore the frames ourselves.
Implement basic support for concurrency (Linux/macos only)
Changes (most new code is in `src/threads.rs` and `src/shims/foreign_items/posix.rs`):
1. Move the stack from `Machine` to a newly created `Thread` struct.
2. Add a `ThreadSet` struct that manages the threads.
3. Change `canonical_alloc_id` to create a unique allocation id for each thread local and thread (the responsible struct is `ThreadLocalStorage`)
4. Change the code to execute the thread local destructors immediately when a thread terminates.
5. Add the most basic round-robin scheduler.
This pull request depends on [these changes to the compiler](https://github.com/rust-lang/rust/pull/70598).
Details to the found in https://github.com/rust-lang/miri/issues/1364.
Note that this was not a found in a `master` or production release of ink!, however without analysing the code via `miri` this could have potentially happened.
