@@ -6,7 +6,7 @@ use std::borrow::{Borrow, Cow};
66use std:: hash:: Hash ;
77
88use rustc_middle:: mir;
9- use rustc_middle:: ty:: { self , query :: TyCtxtAt , Ty } ;
9+ use rustc_middle:: ty:: { self , Ty } ;
1010use rustc_span:: def_id:: DefId ;
1111
1212use super :: {
@@ -230,10 +230,11 @@ pub trait Machine<'mir, 'tcx>: Sized {
230230 id
231231 }
232232
233- /// Called when converting a `ty::Const` to an operand.
233+ /// Called when converting a `ty::Const` to an operand (in
234+ /// `eval_const_to_op`).
234235 ///
235- /// Miri uses this callback for creating unique allocation ids for thread
236- /// locals. In Rust, one way for creating a thread local is by marking a
236+ /// Miri uses this callback for creating per thread allocations for thread
237+ /// locals. In Rust, one way of creating a thread local is by marking a
237238 /// static with `#[thread_local]`. On supported platforms this gets
238239 /// translated to a LLVM thread local for which LLVM automatically ensures
239240 /// that each thread gets its own copy. Since LLVM automatically handles
@@ -243,11 +244,12 @@ pub trait Machine<'mir, 'tcx>: Sized {
243244 /// plan is to change MIR to make accesses to thread locals explicit
244245 /// (https://github.com/rust-lang/rust/issues/70685). While the issue 70685
245246 /// is not fixed, our current workaround in Miri is to use this function to
246- /// reserve fresh allocation ids for each thread. Please note that here we
247- /// only **reserve** the allocation ids; the actual allocation for the
248- /// thread local statics is done in `Memory::get_global_alloc`, which uses
249- /// `resolve_maybe_global_alloc` to retrieve information about the
250- /// allocation id we generated.
247+ /// make per-thread copies of thread locals. Please note that we cannot make
248+ /// these copies in `canonical_alloc_id` because that is too late: for
249+ /// example, if one created a pointer in thread `t1` to a thread local and
250+ /// sent it to another thread `t2`, resolving the access in
251+ /// `canonical_alloc_id` would result in pointer pointing to `t2`'s thread
252+ /// local and not `t1` as it should.
251253 #[ inline]
252254 fn eval_maybe_thread_local_static_const (
253255 _ecx : & InterpCx < ' mir , ' tcx , Self > ,
@@ -256,22 +258,6 @@ pub trait Machine<'mir, 'tcx>: Sized {
256258 Ok ( val)
257259 }
258260
259- /// Called to obtain the `GlobalAlloc` associated with the allocation id.
260- ///
261- /// Miri uses this callback to resolve the information about the original
262- /// thread local static for which `canonical_alloc_id` reserved a fresh
263- /// allocation id. Since `canonical_alloc_id` does not create the actual
264- /// allocation and the reserved allocation id has no reference to its
265- /// parent, we need to ask Miri to retrieve information for us.
266- #[ inline( always) ]
267- fn resolve_maybe_global_alloc (
268- tcx : TyCtxtAt < ' tcx > ,
269- _memory_extra : & Self :: MemoryExtra ,
270- id : AllocId ,
271- ) -> Option < mir:: interpret:: GlobalAlloc < ' tcx > > {
272- tcx. alloc_map . lock ( ) . get ( id)
273- }
274-
275261 /// Called to initialize the "extra" state of an allocation and make the pointers
276262 /// it contains (in relocations) tagged. The way we construct allocations is
277263 /// to always first construct it without extra and then add the extra.
0 commit comments