feat: Support fstat in linux

[hulxv]

Close #4684

[rustbot]

Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two.
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

[RalfJung]

Thanks for the PR! However, there are some things missing.

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[RalfJung]

Please use @rustbot ready when the PR is ready for review again.

However, it seems like there are some CI failures that need to be dealt with before this is ready?

[hulxv]

@rustbot ready

[hulxv]

for some reason, it fails on aarch64 only

  full stderr:
  hello dup fd
  error: Undefined Behavior: memory access failed: attempting to access 8 bytes, but got alloc23440+0x78 which is at or beyond the end of the allocation of size 120 bytes
    --> tests/pass-dep/libc/libc-fs.rs:465:24
     |
  LL |     let res = unsafe { libc::fstat(fd, &mut stat) };
     |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here
     |
     = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
     = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
  help: alloc23440 was allocated here:
    --> tests/pass-dep/libc/libc-fs.rs:464:9
     |
  LL |     let mut stat: libc::stat = unsafe { MaybeUninit::zeroed().assume_init() };
     |         ^^^^^^^^
     = note: BACKTRACE (of the first span):
     = note: inside `test_fstat` at tests/pass-dep/libc/libc-fs.rs:465:24: 465:50
  note: inside `main`
    --> tests/pass-dep/libc/libc-fs.rs:45:5
     |
  LL |     test_fstat();
     |     ^^^^^^^^^^^^
  
  note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace
  
  error: aborting due to 1 previous error
  
  
  full stdout:
  hello dup fd

maybe the problem comes from libc itself in aarch64? It's 128 bits, but it allocates 120. I think it's related to the size of libc::stat. Maybe the problem is related to the padding size on aarch64. We can do something like that:

#[repr(C)]
struct SafeStat {
    stat: libc::stat,
    _pad: [u64; 16],
}
let mut safe_stat: SafeStat = unsafe { MaybeUninit::zeroed().assume_init() };
let stat_ptr = &mut safe_stat as *mut SafeStat as *mut libc::stat;

let res = unsafe { libc::fstat(fd, stat_ptr) };

what do you think?

[RalfJung]

Note that the target it failed on is x86_64-unknown-freebsd. So you are looking at the wrong target.

We definitely should not do anything like that in the test. If a test fails, usually that means you have to fix the code, not the test.

[RalfJung]

I looked into the BSD issue. Apparently on BSD there is libc::unix::bsd::freebsdlike::freebsd::freebsd12::stat and libc::stat and those are not the same type. Great. Who on Earth screwed that up?!??

The fix for us is fairly simple though -- we just trust the type signature used by the program, since double-checking it is apparently impractically difficult:

diff --git a/src/shims/unix/fs.rs b/src/shims/unix/fs.rs
index 16214d7ef..c33100b24 100644
--- a/src/shims/unix/fs.rs
+++ b/src/shims/unix/fs.rs
@@ -130,7 +130,11 @@ trait EvalContextExtPrivate<'tcx>: crate::MiriInterpCxExt<'tcx> {
         let (modified_sec, modified_nsec) = metadata.modified.unwrap_or((0, 0));
         let mode = metadata.mode.to_uint(this.libc_ty_layout("mode_t").size)?;
 
-        let buf = this.deref_pointer_as(buf_op, this.libc_ty_layout("stat"))?;
+        // We do *not* use `deref_pointer_as` here since determining the right pointee type
+        // is highly non-trivial: it depends on which exact alias of the function was invoked
+        // (e.g. `fstat` vs `fstat64`), and then on FreeBSD it also depends on the ABI level
+        // which can be different between the libc used by std and the libc used by everyone else.
+        let buf = this.deref_pointer(buf_op)?;
         this.write_int_fields_named(
             &[
                 ("st_dev", metadata.dev.into()),

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[RalfJung]

I have taken the liberty to fix the last few remaining issues. Thanks for giving this a shot!

resolved