Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nia-e
Copy link
Contributor

@nia-e nia-e commented Jul 8, 2025

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!

@nia-e
Copy link
Contributor Author

nia-e commented Jul 8, 2025

Ah, I forgot I rebased this on top of #4435. Just the last commit is relevant for now

@nia-e nia-e force-pushed the trace-incorporate-events branch 2 times, most recently from acbf7f3 to a8694a4 Compare July 8, 2025 08:52
@RalfJung RalfJung added the S-blocked Status: blocked on something happening somewhere else label Jul 8, 2025
@nia-e nia-e force-pushed the trace-incorporate-events branch 5 times, most recently from 4326ab5 to 180efe5 Compare July 8, 2025 09:30
@RalfJung
Copy link
Member

RalfJung commented Jul 8, 2025

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.

@nia-e
Copy link
Contributor Author

nia-e commented Jul 9, 2025

I actually wrote some! Just didn't know if they belong here. I'll add them, though

@nia-e nia-e force-pushed the trace-incorporate-events branch 5 times, most recently from 6d91006 to 3d16495 Compare July 9, 2025 19:51
rust-bors bot added a commit to rust-lang/rust that referenced this pull request Jul 9, 2025
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`
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 12, 2025
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`
fmease added a commit to fmease/rust that referenced this pull request Jul 13, 2025
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``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 13, 2025
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```
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 13, 2025
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````
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 13, 2025
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`````
rust-timer added a commit to rust-lang/rust that referenced this pull request Jul 13, 2025
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`````
github-actions bot pushed a commit that referenced this pull request Jul 14, 2025
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`````
@nia-e nia-e force-pushed the trace-incorporate-events branch from 5283a29 to 6454be8 Compare July 14, 2025 07:21
@nia-e
Copy link
Contributor Author

nia-e commented Jul 14, 2025

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

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-blocked Status: blocked on something happening somewhere else labels Jul 14, 2025
Copy link
Member

@RalfJung RalfJung left a 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. ;)

@nia-e
Copy link
Contributor Author

nia-e commented Jul 15, 2025

This should address review, lmk if there's anything more!

@nia-e nia-e force-pushed the trace-incorporate-events branch from fc5760e to 94bf0d2 Compare July 15, 2025 11:42
@nia-e
Copy link
Contributor Author

nia-e commented Jul 15, 2025

nvm, seems like I messed something up, just a sec 😭

@nia-e nia-e force-pushed the trace-incorporate-events branch 2 times, most recently from b9e4399 to 59bc0a7 Compare July 15, 2025 12:30
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) {
Copy link
Member

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. ;)

@RalfJung
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Jul 15, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 15, 2025

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

@nia-e nia-e force-pushed the trace-incorporate-events branch from 8bfa229 to 8ed4303 Compare July 15, 2025 12:45
@nia-e
Copy link
Contributor Author

nia-e commented Jul 15, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jul 15, 2025
// 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
Copy link
Member

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.

@RalfJung
Copy link
Member

This looks great, thanks! After resolving the last nits, please squash the commits using ./miri squash. Then write @rustbot ready after you force-pushed the squashed PR.

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: Waiting for the PR author to address review comments and removed S-waiting-on-review Status: Waiting for a review to complete labels Jul 15, 2025
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
@nia-e nia-e force-pushed the trace-incorporate-events branch from 8ed4303 to 377c515 Compare July 15, 2025 21:42
@nia-e
Copy link
Contributor Author

nia-e commented Jul 15, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jul 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Waiting for a review to complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants