Support generating backtraces in emulated code

[Aaron1011]

Once rust-lang/rust#60026 is merged, Miri will have support for panicking via unwinding.

However, we will still lack support for printing backtraces from the panic hook (currently, Miri builds libstd without the backtrace feature, so nothing is printed).

Unlike the implementation of panicking, getting this to work will require modifying a third party-crate. Specifically, we will need to modify backtrace-rs, which is used by libstd to generate backtraces.

This will require Miri to expose some sort of API to the outside world for the first time. At a minimum, backtrace-rs needs a way to get a list of Frames from Miri (the definition of Frame is up to us).

This bring up an interesting question: do we ever want to stabilize this API? For printing panic backtraces, it's sufficient for this API to be unstable - Miri builds libstd using nightly Rust, so we can just enable some internal feature. However, it seems reasonable for third-party crates using backtrace-rs to 'just work' under Miri. This means that whatever mechanism backtrace-rs uses to communicate with Miri will (eventually) need to be stable as well.

One way to go about this would be to have Miri define some special foreign function (e.g. __rust_miri_magic_get_backtrace), rather than an intrinsic. Conceptually, this would make Miri just another target platform, which happens to guarantee the existence of some foreign function.

[oli-obk]

So far our strategy has been to implement the platform specific logic, but just looking at https://github.com/rust-lang/backtrace-rs/blob/master/src/windows.rs makes me shiver.

For things like this where there's no use in having miri run the platform specific logic to find UB, I think it would be fine to add cfg(miri) logic to backtrace-rs

[Aaron1011]

Supporting the full backtrace-rs api is going to trickier than I had imagined.

The main problem is symbol_address - it returns a *mut c_void which can later be passed to backtrace::resolve.

Of course, Miri doesn't have a flat address space. I think the best approach would be to cast Span.lo to a raw pointer (for the span of the calling frame). Span.lo is a BytePos, which is always 32 bits - so we can do this on both 32-bit and 64-bit platforms. We can throw away span.hi, since all we need is the filename, line number, and function name - all of which we can obtain with just the lower half of the span.

This approach avoids allocating any additional memory, so repeatedly calling Backtrace::new() won't cause memory usage to grow.

[oli-obk]

Neat trick, but how do we do the inverse? Creating a BytePos from user-given numbers seems dangerous.

[bjorn3]

The main problem is symbol_address - it returns a *mut c_void which can later be passed to backtrace::resolve.

Maybe return fn_ptr as *mut c_void? Function allocations are only created once per Instance, right? If so, that means that extra memory usage is bounded with this approach, just like your BytePos proposal.

[Aaron1011]

Neat trick, but how do we do the inverse? Creating a BytePos from user-given numbers seems dangerous.

How so? We can check if it's in the valid range for a Span - it may be a nonsensical span, but we can easily handle that case.

[oli-obk]

I assumed that rustc would simply panic on out of bounds spans

I like the function pointer idea

[Aaron1011]

Using function pointers would make us lose precise line number information, which seems like a really unfortunate limitation.

[oli-obk]

You can use the offset part of the pointer to encode an additional 32bit

[Aaron1011]

@oli-obk: I'm not sure what you mean, or how that could work on 32-bit platforms.

Using the lower BytePos of the Span gives us exactly the information we need, doesn't require any additional allocations at all, and works on both 32-bit and 64-bit platforms.

[oli-obk]

I guess. It just feels a bit hacky that we'd expose a compiler internal integer. Especially since they can change arbitrarily between runs

[Aaron1011]

It just feels a bit hacky that we'd expose a compiler internal integer. Especially since they can change arbitrarily between runs

Doesn't that apply to Miri function pointers as well?

[oli-obk]

You can't get at that information. It's not exposed to the program.

in https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=96c11f4863d9816868d9a09b0198a26b you will not see a rustc specific integer, but just the integer that you get from the ptr2int conversion which is a program-specific counter