Allow backtraces to cross thread boundaries

[actuallyatoaster]

Fixes #4066

When a thread is spawned we store the ID of the spawning thread as well as a backtrace to the spawn location. When there's an error we can traverse upwards, displaying a backtrace up to the main thread.

For instance, with the following program:

extern "C" {
    fn unknown();
}

fn bad() {
    unsafe { unknown() }
}

fn main() {
    std::thread::spawn(bad);
}

Whereas previously we would see:

error: unsupported operation: can't call foreign function `unknown` on OS `linux`
 --> tests/temp.rs:6:14
  |
6 |     unsafe { unknown() }
  |              ^^^^^^^^^ can't call foreign function `unknown` on OS `linux`
  |
  = help: if this is a basic API commonly used on this target, please report an issue with Miri
  = help: however, note that Miri does not aim to support every FFI function out there; for instance, we will not support APIs for things such as GUIs, scripting languages, or databases
  = note: BACKTRACE on thread `unnamed-1`:
  = note: inside `bad` at tests/temp.rs:6:14: 6:23

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

We now have:

error: unsupported operation: can't call foreign function `unknown` on OS `linux`
  --> tests/temp.rs:6:14
   |
6  |     unsafe { unknown() }
   |              ^^^^^^^^^ can't call foreign function `unknown` on OS `linux`
   |
   = help: if this is a basic API commonly used on this target, please report an issue with Miri
   = help: however, note that Miri does not aim to support every FFI function out there; for instance, we will not support APIs for things such as GUIs, scripting languages, or databases
   = note: BACKTRACE on thread `unnamed-1`:
   = note: inside `bad` at tests/temp.rs:6:14: 6:23
   = note: thread `unnamed-1` was spawned by thread `main`
   = note: inside `std::sys::pal::unix::thread::Thread::new` at /home/reimu/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/sys/pal/unix/thread.rs:84:19: 84:86
   = note: inside `std::thread::Builder::spawn_unchecked_::<'_, fn() {bad}, ()>` at /home/reimu/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/thread/mod.rs:600:30: 600:64
   = note: inside `std::thread::Builder::spawn_unchecked::<fn() {bad}, ()>` at /home/reimu/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/thread/mod.rs:467:32: 467:62
   = note: inside `std::thread::Builder::spawn::<fn() {bad}, ()>` at /home/reimu/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/thread/mod.rs:400:18: 400:41
   = note: inside `std::thread::spawn::<fn() {bad}, ()>` at /home/reimu/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/thread/mod.rs:730:5: 730:28
note: inside `main`
  --> tests/temp.rs:10:5
   |
10 |     std::thread::spawn(bad);
   |     ^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

[oli-obk]

You'll need to bless the windows tests, too. It should suffice to pass --target with a windows target, no windows host needed

[RalfJung]

I have some nits.

[RalfJung]

Suggested change

	// ThreadId that spawned this thread and backtrace to where this thread was spawned
	/// ThreadId that spawned this thread and backtrace to where this thread was spawned.

[RalfJung]

This comment is not right, the first frame is not the error site.

[RalfJung]

This is duplicating existing logic. Can you move this into a shared helper fn?

[RalfJung]

It's not pretty to show this for every backtrace. We spent a bunch of effort making backtraces nice, i.e. they usually stop at main and don't go all the way to the start lang item. We should do something similar here to avoid drowning the user in noise.

I could imagine two options:

• we mark these frames as #[caller_location] in std (we have done this for a bunch of other functions to make backtraces prettier)
• when pruning the stack for another thread, we also remove all non-local frames at the top

I am leaning towards the first option since the second option might prune too much when the thread is spawned deep inside some other library.