`miri` no longer builds after rust-lang/rust#95624

[rust-highfive]

Hello, this is your friendly neighborhood mergebot.
After merging PR #95624, I observed that the tool miri no longer builds.
A follow-up PR to the repository https://github.com/rust-lang/miri is needed to fix the fallout.

cc @Dylan-DPC, do you think you would have time to do the follow-up work?
If so, that would be great!

[RalfJung]

#95035 makes this somewhat tricky, Miri will have to support more ways of using futex. (It supported enough for the thread parker implementation, but now it seems we are using more of that API.)

[RalfJung]

We support FUTEX_WAIT and FUTEX_WAKE, but not FUTEX_WAIT_BITSET.

@m-ou-se what would you say is a good place to learn about futex semantics, ideally suitable as a reference documentation that one can follow if one wants to do a reimplementation in an interpreter?

[m-ou-se]

The man page for the Linux syscall is the best documentation/reference: https://man7.org/linux/man-pages/man2/futex.2.html

FUTEX_WAIT_BITSET shouldn't be hard to implement. I can work on Miri support for it. :)

[RalfJung]

That would be great. :)

Best to start with ./rustup-toolchain 306ba8357fb36212b7d30efb9eb9e41659ac1445 (rather than the usual ./rustup-toolchain HEAD) as otherwise you will have to also deal with other breakage that happened after the futex change.

[m-ou-se]

This adds support for FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET in Miri: rust-lang/miri#2054

[RalfJung]

The next trouble is #95469 -- somehow this broke printing to stdout in Miri on Windows targets, which now just loops infinitely. @ChrisDenton any idea what might be going on?

[ChrisDenton]

I made a quick summary in #95759 but still need to investigate properly. Short version is that in some cases we're passing asynchronous handles to child processes, which is unsound when read synchronously (but mostly seemed to work in practice).

Though I'm not actually sure why that should make it loop infinitely since it's calling std::sys::abort_internal?

[RalfJung]

Note that this happens even on a Linux host interpreting Windows target MIR. So it might be a different problem?

[RalfJung]

The odd thing is, these tests do not even read/write a file (Miri does not support that on Windows targets). They just write to stderr/stdout. If NtRead/WriteFile were ever executed, Miri would stop immediately since it does not support those operations.

[ChrisDenton]

Oh right! Hm... I'm not really sure why that be. The changes are limited to reading and writing from a handle.