Miri does not work with a sysroot built without cfg(miri)

[bjorn3]

This is necessary to be able to use a libstd compiled without cfg(miri), yet still with -Zalways-encode-mir. In particular for #722 (comment) I had to use the same standard library as would be linked against for regular programs as cargo-miri to build a new standard library with -Zalways-encode-mir and cfg(miri) doesn't work on wasm. Because the poll syscall is missing, I had to patch the standard library to never try the poll based fast path for detecting if all stdio fds are open.

[saethlin]

Can you explain why you need to compile libstd without cfg(miri)? I don't think we can realistically support a working libstd in Miri without cfg(miri) going forward.

[bjorn3]

I need the exact same libstd be used for compiling rustc against and to run miri with. Without cargo-miri working, the only way to get a sysroot for miri to use, is to literally reuse the same sysroot used for regular compilation as produced by bootstrap. This worked just fine for hello world at least if I patched bootstrap to pass -Zalways-encode-mir when building the stdlib.

[saethlin]

This worked just fine for hello world at least if I patched bootstrap to pass -Zalways-encode-mir when building the stdlib.

Yes but it will definitely not work for some programs, and I'm not sure why we'd make any effort to keep it working even for hello-world. For example, panicking and backtraces have Miri-specific code.

[RalfJung]

I agree with Ben, we can only reasonably support sysroots built with cfg(miri).
Of course if someone wants to add "poll" support, we'll take it, but we'll not make any promises about non-cfg(miri) sysroots.

I need the exact same libstd be used for compiling rustc against and to run miri with.

Why?

Without cargo-miri working,

Why doesn't it work?

[bjorn3]

Why doesn't it work?

Cargo can't run on wasm32-wasi as spawning processes is not supported. cargo-miri fails for a similar reason and in addition there was some weird compilation error I didn't investigate.

[oli-obk]

I would not expect to be able to run miri from within wasi. We should use cross compilation to run against wasi targets.

If you want to run miri in a wasi environment, build a target libstd with cfg miri on a supported host and ship those binaries

[oli-obk]

The sysroot that uses cfg(miri) is not the one that can be used to compile miri itself.

[bjorn3]

My goal is to have a miri playground run entirely in the browser.

The sysroot that uses cfg(miri) is not the one that can be used to compile miri itself.

I used one with cfg(miri) disabled both for compiling miri against and to use as sysroot at runtime.

If you want to run miri in a wasi environment, build a target libstd with cfg miri on a supported host and ship those binaries

Getting that working is non-trivial. It doesn't mesh with bootstrap and outside of that, getting the exact same rustc version to do compilation with isn't easy (the output of the build does contain a rustc compiled to wasm, but cargo doesn't know how to use it) and it no longer has a simple ./x.py install command to build everything.

[RalfJung]

I'm afraid an environment which can't even run cargo is too cursed for us to support.

But as I said above, if it's just about "poll", that can land on its own merits. However you'll run into a bunch of other places in the sysroot that (need to) use cfg(miri).

[oli-obk]

getting the exact same rustc version to do compilation with isn't easy

Whichever rustc you use to build wasi miri should be used to build cfg(miri) libstd artifacts. After stage2 there should not be any issues with differing compiler version

[RalfJung]

Also, ./x.py test miri --stage 0 works, so there's a way to get Miri to work even without completing the bootstrap cycle. Seems like that way of running Miri should also work on wasi then?

[RalfJung]

But anyway, the discussion here now really is part of #722 (comment). It doesn't seem like there's anything being tracked separately? So let's close this.

I guess we could track adding "poll" support, but then there are so many shims missing, it's not worth having an issue for each one of them. I guess that was your intent when you opened the issue, but then it got side-tracked based on the motivation you stated -- sorry for that.