Allow foreign rust functions

[elichai]

Hi,
Is it possible to allow miri to evaluate foreign calls to rust functions?
Example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3cddf97b737ae015f92093c9bab2461e

[RalfJung]

It is probably possible, yes. But I do not know the best way to implement this -- somehow, Miri would have to find the function with a given extern name.

[pvdrz]

Even though I think this is possible, how do we guarantee that allowing to execute extern code would not compromise miri's capability of detecting UB?

[RalfJung]

It's not actually extern code. The implementation is Rust code as well so we just go on interpreting.

[oli-obk]

I have absolutely no idea whether this is the right thing, but we may be able to just iterate over all crates and call https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/struct.TyCtxtAt.html#method.exported_symbols in order to collect the name -> DefId map and continue interpretation at the new def ID.

An extern other than "Rust" should also emit an error if unwinding happens across that boundary

[tomtau]

I have a similar related question -- will it be possible to allow Miri evaluate foreign statics?

extern "C" {
    pub static something: *const Something;
...
}

[RalfJung]

I'm afraid the question is not very related at all. The issue here is specifically about calling extern fn that are implemented in Rust (somewhere in the current crate tree).

We already emulate one foreign static, and support for others can be added. But this is like function shims: you need to actually write the code that implements whatever interaction with that foreign static would happen in real code. If you have s specific well-known foreign static that you think should be supported, please open a new issue (just like we have issues to support calling specific foreign functions).

For general support for arbitrary foreign statics, I don't even know what that would mean (should Miri just guess their value...?!?), but it seems related to general FFI support so that would be #11.

[tomtau]

Thanks, yes, #11 is indeed more relevant.