-
Notifications
You must be signed in to change notification settings - Fork 390
trace: incorporate events #4456
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
base: master
Are you sure you want to change the base?
Conversation
Ah, I forgot I rebased this on top of #4435. Just the last commit is relevant for now |
acbf7f3
to
a8694a4
Compare
4326ab5
to
180efe5
Compare
What this PR definitely needs is some tests. :) Remember that tracing mode is off-by-default; none of the tests hit the tracing infra. So this needs some new native-mode tests that specifically check that we detect the ranges properly. For instance, sharing a 2-field uninit struct with C, having C initialize the first field, and then reading the 2nd field -- that should be UB. |
I actually wrote some! Just didn't know if they belong here. I'll add them, though |
6d91006
to
3d16495
Compare
interpret/allocation: expose init + write_wildcards on a range Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? `@RalfJung`
interpret/allocation: expose init + write_wildcards on a range Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? `@RalfJung`
interpret/allocation: expose init + write_wildcards on a range Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? ``@RalfJung``
interpret/allocation: expose init + write_wildcards on a range Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? ```@RalfJung```
interpret/allocation: expose init + write_wildcards on a range Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? ````@RalfJung````
interpret/allocation: expose init + write_wildcards on a range Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? `````@RalfJung`````
Rollup merge of #143634 - nia-e:init-and-wildcards, r=RalfJung interpret/allocation: expose init + write_wildcards on a range Part of rust-lang/miri#4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? `````@RalfJung`````
interpret/allocation: expose init + write_wildcards on a range Part of #4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side? r? `````@RalfJung`````
5283a29
to
6454be8
Compare
I did readd logic (not much code) for whether an access spands multiple allocations since from what I understand this is theoretically allowed by LLVM at least and I'm a little scared it could happen in the wild; but I can replace that with just an assertion that accesses span a single allocation and ICE/error otherwise. @rustbot ready |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay that's really cool that this works, this is pure magic.^^
I still have a bunch of comments, of course. ;)
This should address review, lmk if there's anything more! |
fc5760e
to
94bf0d2
Compare
nvm, seems like I messed something up, just a sec 😭 |
b9e4399
to
59bc0a7
Compare
let p_map = alloc.provenance(); | ||
for idx in overlap { | ||
// If a provenance was read by the foreign code, expose it. | ||
if let Some(prov) = p_map.get(Size::from_bytes(idx), this) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a FIXME saying that we should really have a get_range
on ProvenanceMap
.
(Here's a next PR for you if you are interested. ;)
@rustbot author |
Reminder, once the PR becomes ready for a review, use |
8bfa229
to
8ed4303
Compare
@rustbot ready |
// The start of the overlap range will be the greater of the alloc base address and the | ||
// lowest remaining address in the access' range; the end will be the lesser of the end | ||
// of the allocation and the end of the access' range. Both are then shifted by `alloc_addr` | ||
// The start of the overlap range will be `curr`; the end will be the lesser of the end of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please make it clear that this range is in terms of offsets inside the allocation, i.e., relative to alloc_addr
.
This looks great, thanks! After resolving the last nits, please squash the commits using @rustbot author |
tests allow accesses to span multiple allocs oopsie fixup rebase Apply suggestions from code review Co-authored-by: Ralf Jung <[email protected]> review apparently x86 has signed types for registers but x64 has unsigned... i give up doc for certain write more review last review
8ed4303
to
377c515
Compare
@rustbot ready |
If tracing is enabled, use the info from the trace to actually update Miri's state. Pending a small change to rustc to expose some necessary interfaces to handle writes, this should be good!