Make weak syscalls in std work. #1629
Conversation
std now looks up `getrandom` and `statx` with `dlsym` before attempting to use `syscall(SYS_.., ..)`. It also now passes all arguments as a machine-sized word, instead of their original types.
I removed that. That issue should only be closed when the submodule got bumped. |
| this.read_scalar(flags)?.to_i32()?; | ||
| let flags = this.read_scalar(flags)?; | ||
| // Either `i32` or `isize` is fine. | ||
| if flags.to_machine_isize(this).is_err() { |
There was a problem hiding this comment.
This is extremely suspicious, I will have to think about what to do here. is_err is never okay; Miri should not catch "exceptions" (that leads to all sots of problems).
There was a problem hiding this comment.
yea, I think the right fix is to check flags.ty.kind() and then choose a different to_* method
edit: ah, saw your other PR
There was a problem hiding this comment.
First I need to become convinced that this is not UB.
There was a problem hiding this comment.
Variadic functions like this, especially syscall, are pretty annoying. For the ABI it doesn't matter if you pass a char or int or long or a pointer, those just all count as 'one argument' or 'one register'. But unless miri is going to emulate the actual processor registers to simulate the ABI, this is always going to be a bit hacky. :( (The futex implementation had the problem with accepting an integer for the pointer argument.)
There was a problem hiding this comment.
I don't know if the C standard defines this behaviour, but the syscall wrapper isn't a C function. It's written in assembly and fully depends on knowing everything about the ABI.
There was a problem hiding this comment.
(The futex implementation had the problem with accepting an integer for the pointer argument.)
Those are the same size, so they are the same ABI even as far as Rust's Layout/ABI code is concerned.
This is different. I spent a lot of time making sure Miri detects ABI mismatches during function calls, and I'd consider different sizes to be ABI mismatches. You can't even transmute these!
There was a problem hiding this comment.
I don't know if the C standard defines this behaviour, but the syscall wrapper isn't a C function. It's written in assembly and fully depends on knowing everything about the ABI.
It is called with the "C" ABI though, so its rules apply.
There was a problem hiding this comment.
Also note that Miri's getrandom function is also used to shim the getrandom libc function, not just direct calls to the syscall.
There was a problem hiding this comment.
I don't know if the C standard defines this behaviour, but the syscall wrapper isn't a C function. It's written in assembly and fully depends on knowing everything about the ABI.
It is called with the
"C"ABI though, so its rules apply.
@RalfJung From what little I know of the x86_64 "C" ABI, you can call an extern "C" fn(u64) as if it was an extern "C" fn(u8) because in both cases the argument is passed in the same 64-bit register[0]. I think that is what @m-ou-se meant by "fully depends on knowing everything about the ABI."
[0]: See e.g. https://godbolt.org/z/a35MYb, keeping in mind that edi (resp. eax) is an alias to the low 32 bits of rdi (resp. rax).
There was a problem hiding this comment.
you can call an extern "C" fn(u64) as if it was an extern "C" fn(u8) because in both cases the argument is passed in the same 64-bit register[0]
And which 64-bit value will the function see then? Maybe the compiler passes some junk in the higher bytes?
Also, the code we are looking at in rustc runs on many targets. So just looking at the x86_64 ABI does not help.
|
Oh, right. Submodules. :) Thanks. |
|
Two things broke at once, so I had to fix them together in #1630. I made your PR part of that. Thanks for helping fixing Miri! |
Since rust-lang/rust#78785,
stdlooks upgetrandomandstatxwithdlsymbefore attempting to usesyscall(SYS_.., ..).It also now passes all arguments as a machine-sized word, instead of their original types.