Print hex dump of alloc on reading undef bytes
Here's a small addition I made locally to the UB diagnostics, in case you're interested in it. This PR calls `dump_alloc()` on the relevant allocation if Miri fails on UB due to reading undefined bytes. This came in handy when diagnosing such an issue in a large program using unsafe Rust, in part because it wasn't deterministic enough to use `-Zmiri-track-alloc-id=`. If you'd like to put this behind another -Z flag, let me know.
Handle std::sync::atomic::spin_loop_hint()
This PR adds support for `std::sync::atomic::spin_loop_hint()` by implementing the `llvm.x86.sse2.pause` intrinsic when the target is x86-based. It appears this is the first LLVM intrinsic in foreign_items, so I added a couple match blocks to handle it or fall through to the different OS-specific methods. I added a basic smoke test to `tests/run-pass/sync.rs`. I came across this by way of `crossbeam::utils::Backoff::spin()`, FWIW.
implement float_to_int_unchecked
@hanna-kruppe would be great if you could have a look at this.
`float.rs` tests legal casts. `test_cast` checks that both `as` casts and unchecked casts work (i.e., these are not saturating). The `compile-fail` tests should ensure that illegal casts via the intrinsic are detected as such.
Fixes https://github.com/rust-lang/miri/issues/1264
Implement `mach_timebase_info` for macOS
Since we return nanoseceonds instead of ticks from `mach_absolute_time`, we don't need to scale the absolute time
Fixes#1288
add empty line before backtrace, to separate it from help text
I think this improves how things look, and makes it easier to see the help text (it currently kind of drowns next to the backtrace).
Before:
```
error: unsupported operation: Miri does not support threading
--> /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
|
68 | let ret = libc::pthread_create(&mut native, &attr, thread_start, &*p as *const _ as *mut _);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Miri does not support threading
|
= help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
= note: inside `std::sys::unix:🧵:Thread::new` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
= note: inside `std:🧵:Builder::spawn_unchecked::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:492:26
= note: inside `std:🧵:Builder::spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:386:18
= note: inside `std:🧵:spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:619:5
note: inside `main` at tests/compile-fail/thread-spawn.rs:6:5
--> tests/compile-fail/thread-spawn.rs:6:5
|
6 | thread::spawn(|| {});
| ^^^^^^^^^^^^^^^^^^^^
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:34
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:73
= note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<[closure@DefId(1:6030 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]::{{closure}}[0]) 0:&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys_common/backtrace.rs:130:5
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:13
= note: inside `std::panicking::try::do_call::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:331:40
= note: inside `std::panicking::try::<i32, [closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe]>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:274:15
= note: inside `std::panic::catch_unwind::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panic.rs:394:14
= note: inside `std::rt::lang_start_internal` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:51:25
= note: inside `std::rt::lang_start::<()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:5
```
After:
```
error: unsupported operation: Miri does not support threading
--> /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
|
68 | let ret = libc::pthread_create(&mut native, &attr, thread_start, &*p as *const _ as *mut _);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Miri does not support threading
|
= help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
= note: inside `std::sys::unix:🧵:Thread::new` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/thread.rs:68:19
= note: inside `std:🧵:Builder::spawn_unchecked::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:492:26
= note: inside `std:🧵:Builder::spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:386:18
= note: inside `std:🧵:spawn::<[closure@tests/compile-fail/thread-spawn.rs:6:19: 6:24], ()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/thread/mod.rs:619:5
note: inside `main` at tests/compile-fail/thread-spawn.rs:6:5
--> tests/compile-fail/thread-spawn.rs:6:5
|
6 | thread::spawn(|| {});
| ^^^^^^^^^^^^^^^^^^^^
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:34
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:73
= note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<[closure@DefId(1:6030 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]::{{closure}}[0]) 0:&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys_common/backtrace.rs:130:5
= note: inside closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:13
= note: inside `std::panicking::try::do_call::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:331:40
= note: inside `std::panicking::try::<i32, [closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe]>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panicking.rs:274:15
= note: inside `std::panic::catch_unwind::<[closure@DefId(1:6029 ~ std[2f86]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/panic.rs:394:14
= note: inside `std::rt::lang_start_internal` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:51:25
= note: inside `std::rt::lang_start::<()>` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:5
```
What do you think?
Add shims for RwLock::try_read/RwLock::try_write
This implements proper locking so that we can check for reentrancy and implement the `try_*` methods.
Fixes https://github.com/rust-lang/miri/issues/781
Rust bootstrap sysroot now has src in the same place as rust-src
So we can remove a special hack. I checked this locally to confirm it works.
Cc https://github.com/rust-lang/rust/pull/70642 @eddyb
Add support for 'std::time::Instant' in Windows
Add support for creating `std::time::Instant` in Windows
Includes shims for `QueryPerformanceCounter` & `QueryPerformanceFrequency` in Windows, which are both called in Windows when `std::time::Instant` is created.
Windows docs page ["Acquiring high-resolution time stamps"](https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps) was helpful in learning how `QueryPerformanceCounter` & `QueryPerformanceFrequency` work.
closes#1291
Add support for OpenOptions::create_new()/O_EXCL
This PR extends the POSIX shim for `open` to support the `O_EXCL` flag, when it is used alongside `O_CREAT`, and exercises it by testing `OpenOptions::create_new`.
1. Fix 'fn convert_path_separator' in src/shims/os_str.rs
2. Fix 'fn set_last_error_from_io_error' in src/helpers.rs
3. Minor comment fix for 'fn SetCurrentDirectoryW' in src/shims/env.rs
move OsStr helpers to a separate file
Moved OsStr read/write functions from `src/helpers.rs` to `src/shims/os_str.rs`, in order to keep `src/helpers.rs` from bloating too much.
env shim: make sure we clean up all the memory we allocate
`Machine` memory is not leak-checked, so if we forgot to deallocate part of the env shim memory, we wouldn't even notice. Thus add a dedicated memory kind that is leak-checked.
Abort instead of panic on asserting intrinsics
This fixes#1222
replacing the panic with an abort and a corresponding message.
the stack trace is already printed, this just adds an optional message the caller can pass, and I just pass the same message we passed to the panic but now to the abort instead.
r? @RalfJung
Add directory-related shims
This PR adds support for `mkdir`, `rmdir`, `opendir`, `closedir`, and `readdir64_r`.
Open directory streams are tracked through a HashMap indexed by pointer locations, which holds directory iterators. Since `DIR` is an opaque type in glibc, I represent them with 1-byte allocations, and then just use their pointers in HashMap lookups.
Tests are included to exercise the new functionality.
Fixes#1057
Since we are no longer using "cargo rustc", we now use the rustc
arguments passed by Cargo to determine whether we are building a
build dependency, normal dependency, or "target" (final binary or test)
crate.
Reorganize shims by platform
Fixes https://github.com/rust-lang/miri/issues/1161. I am currently testing which shims belong to which platform. If you are reading this and know the answer for any of those please write me :P
Edit: this is a list of the shims I haven't been able to figure out to which platform they belong:
-~~`malloc`~~
-~~`calloc`~~
-~~`posix_memalign`~~
-~~`free`~~
-~~`realloc`~~
-~~`__rust_alloc`~~
-~~`__rust_alloc_zeroed`~~
-~~`__rust_dealloc`~~
-~~`__rust_realloc`~~
-~~`__rust_maybe_catch_panic`~~
-~~`syscall`~~
-~~`getrandom`~~
-~~`dlsym`~~
-~~`memcmp`~~
-~~`memrchr`~~
-~~`memchr`~~
-~~`strlen`~~
-~~`signal`~~
-~~`sigaction`~~
-~~`sigaltstack`~~
-~~`sysconf`~~
-~~`sched_getaffinity`~~
-~~`isatty`~~
-~~`pthread_key_create`~~
-~~`pthread_key_delete`~~
-~~`pthread_getspecific`~~
-~~`pthread_setspecific`~~
-~~`pthread_attr_init`~~
-~~`pthread_attr_destroy`~~
-~~`pthread_self`~~
-~~`pthread_attr_setstacksize`~~
-~~`pthread_attr_getstack`~~
-~~`pthread_create`~~
-~~`pthread_mutexattr_init`~~
-~~`pthread_mutexattr_settype`~~
-~~`pthread_mutex_init`~~
-~~`pthread_mutexattr_destroy`~~
-~~`pthread_mutex_lock`~~
-~~`pthread_mutex_unlock`~~
-~~`pthread_mutex_destroy`~~
-~~`pthread_rwlock_rdlock`~~
-~~`pthread_rwlock_unlock`~~
-~~`pthread_rwlock_wrlock`~~
-~~`pthread_rwlock_destroy`~~
-~~`pthread_condattr_init`~~
-~~`pthread_condattr_setclock`~~
-~~`pthread_cond_init`~~
-~~`pthread_condattr_destroy`~~
-~~`pthread_cond_destroy`~~
-~~`pthread_atfork`~~
-~~`posix_fadvise`~~
-~~`mmap`~~
-~~`mprotect`~~
Add shim for rename
This adds a straightforward shim for rename, which is used by `std::fs::rename`. Testing is included.
As a heads up, I expect one or two merge conflicts between my PRs, since some of them touch the same `use` statements, or add items near the same places. I'll rebase and fix them as they come up.
Add helper 'alloc_os_str_as_c_str' and use it in env_var emulation
First part of the plan laid out in #707 (comment).
Re-submitting a pull-request for work from #1098 (manual rebasing..)
r? @RalfJung
Add statx shim for linux target
This is an attempt to fix: https://github.com/rust-lang/miri/issues/999 (for linux only)
Currently there is one problem that I haven't been able to solve. `std::fs::metadata` fails because the creation time is not available even though it is provided in the shim code.
In order to inform the caller that the field was provided, the `stx_flag` field must have the bits of `STATX_BTIME` set (which they are). The creation time is in the `stx_btime` field of the `statx` struct (see [1]). The relevant code in `libstd` is here (probably?): https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/fs.rs#L322
Another important point is that we are just providing the fields that are available in "all" platforms (this is, without using any platform specific traits or so). This can be improved later.
References:
[1] Man page: http://man7.org/linux/man-pages/man2/statx.2.html
[2] libc `statx` struct: https://docs.rs/libc/0.2.63/libc/struct.statx.html
Edit: The problem is that my filesystem is not providing it and I thought all filesystems could provide it. I changed the code so it only provides those dates if they are available. now we are ready to go.
r? @RalfJung @oli-obk
Fixes#1064
This ensures that we set the error code properly when a panic unwinds
past `main`.
I'm not sure what the best way to write a test for this is
Fixes#658
This commit adds support for unwinding after a panic. It requires a
companion rustc PR to be merged, in order for the necessary hooks to
work properly.
Currently implemented:
* Selecting between unwind/abort mode based on the rustc Session
* Properly popping off stack frames, unwinding back the caller
* Running 'unwind' blocks in Mir terminators
Not yet implemented:
* 'Abort' terminators
This PR was getting fairly large, so I decided to open it for review without
implementing 'Abort' terminator support. This could either be added on
to this PR, or merged separately.
Fix unchecked memory access for files
This PR takes care of two problems:
- It uses `Memory::(read|write)_bytes` to guarantee that memory accesses are checked (Fixes: https://github.com/rust-lang/miri/issues/1007)
- It removes the `(get|remove)_handle_and` methods which were a little bit cumbersome to use. In particular `remove_handle_and`, because we were using it to avoid borrowing issues before the `Evaluator::memory` field was public.
@RalfJung @oli-obk
