@@ -6,7 +6,7 @@ use std::borrow::{Borrow, Cow};
6
6
use std:: hash:: Hash ;
7
7
8
8
use rustc_middle:: mir;
9
- use rustc_middle:: ty:: { self , query :: TyCtxtAt , Ty } ;
9
+ use rustc_middle:: ty:: { self , Ty } ;
10
10
use rustc_span:: def_id:: DefId ;
11
11
12
12
use super :: {
@@ -230,10 +230,11 @@ pub trait Machine<'mir, 'tcx>: Sized {
230
230
id
231
231
}
232
232
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`).
234
235
///
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
237
238
/// static with `#[thread_local]`. On supported platforms this gets
238
239
/// translated to a LLVM thread local for which LLVM automatically ensures
239
240
/// that each thread gets its own copy. Since LLVM automatically handles
@@ -243,11 +244,12 @@ pub trait Machine<'mir, 'tcx>: Sized {
243
244
/// plan is to change MIR to make accesses to thread locals explicit
244
245
/// (https://github.com/rust-lang/rust/issues/70685). While the issue 70685
245
246
/// 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.
251
253
#[ inline]
252
254
fn eval_maybe_thread_local_static_const (
253
255
_ecx : & InterpCx < ' mir , ' tcx , Self > ,
@@ -256,22 +258,6 @@ pub trait Machine<'mir, 'tcx>: Sized {
256
258
Ok ( val)
257
259
}
258
260
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
-
275
261
/// Called to initialize the "extra" state of an allocation and make the pointers
276
262
/// it contains (in relocations) tagged. The way we construct allocations is
277
263
/// to always first construct it without extra and then add the extra.
0 commit comments