-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stacked Borrows: Incompatibilities with LLVM noalias #86
Comments
That example is straight #87 - we do want to do be able to delay the write to unsafe fn foo(x: &mut u32, raw_ptr: *const u32) -> u32 {
let x: *mut u32 = &mut *x; // stack is now [..., Uniq(N), Shr]
*x = 5; // access a raw pointer, OK because of the Shr.
// this is OK according to stacked borrows because of the Shr tag, but is UB
// according to LLVM noalias and would be hard to make non-UB.
unsafe { *raw_ptr }
} LLVM provenance tracking is unsound around int->ptr casts and the like and not well-defined in any case, so bringing it along is harmful. |
@arielb1 the example in my first post here is basically a duplicate of #87. That issue is resolved by rust-lang/miri#695: the following is now UB. fn main() { unsafe {
let x = &mut 0;
let raw = x as *mut _;
let x = &mut *x; // kill `raw`
let _y = &*x; // this should not activate `raw` again
let _val = *raw; //~ ERROR
} } However, I assume other incompatibilities with LLVM remain, so I'll keep this open. There'll be a blog post on this new Stacked Borrows soon; it'd be great if you could then try to help find new incompatibilities with LLVM @arielb1. |
@comex came up with an example of UB that Miri does not catch, based on Stacked Borrows not tracking raw pointers currently. See here for why we currently cannot do this more precise tracking: We'd have to fix |
Since rust-lang/miri#872, retagging is "shallow" in the sense that only "bare" references are retagged and can be used for reasoning. So, things like This is in contrast to how we compile (with |
Hmm... that might be a good idea for now, but it doesn't seem like a good long-term approach to me, as it implies that single-field structs would no longer be zero-overhead abstractions. |
Yeah. We probably want this for some but not all newtypes. |
|
We also need the "opt-out of |
These types aren't really special, and fixing these is a PR from libstd away. I'd be more comfortable with such PRs if miri were actually able to detect these issues if we were to commit test cases that trigger them. Is this possible? |
Miri used to be able to detect them and I removed that for several reasons -- the main one being that I thought surely Stacked Borrows is too strict here, and we should fix the model instead of complaining about legitimate code. I could certainly bring that back (would require reverting a rustc PR and a Miri PR). Would be interesting to get a lang team opinion on that -- rust-lang/rust#63787 is probably the better place for that discussion, though. |
Miri now tags raw references by default, and the new |
Closing as having been fixed by more recent versions of SB and by TB |
There are programs that are accepted by Stacked Borrows and conflict with LLVM noalias. @arielb1 had the following example in this long discussion on Zulip:
On a high level, the problem is that create a raw reference is like a "broadcast" that lets every raw pointer now access this location, whereas LLVM only lets newly created raw pointers be used for that.
The text was updated successfully, but these errors were encountered: