You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix passive element segment GC roots' endianness (#13230)
* Fix passive element segment GC roots' endianness
Passive element segments were registered as GC roots by converting a `*mut
ValRaw` to a `*mut VMGcRef`. Because we always store GC refs as little endian
inside `ValRaw`, regardless of the target architecture's endianness, this cast
is only valid on little endian systems. This bug was not exposed until the
introduction of the copying collector in
#13107
The fix that this commit makes is to add another kind of GC root for `ValRaw`,
where we can get and set the GC root using `ValRaw` internally, to ensure that
the endianness (and incidentally also the GC ref offsets within the `ValRaw`)
are matched up correctly between the GC root's definition and the collector's
use of it. This brings us to three kinds of GC roots: Wasm stack roots,
`VMGcRef` roots, and `ValRaw` roots.
FWIW, I initially tried to make `VMGcRef` also always store its data as little
endian, but this was a larger, more-invasive change and with feedback like
#13193 (comment)
suggesting the use of `[u8; 4]` instead of `u32` to make the byte ordering
explicit, we break `rustc`'s niche type optimizations (since `VMGcRef` is
non-zero right now). I also investigated making `PassiveElementSegment` an
`enum` or either funcrefs or externrefs, similar to what we do for
`wasmtime::runtime::vm::Table`. This also led to an outsized amount of code
churn and didn't feel like it was paying for itself. Ultimately, I abandoned
these approaches, preferring the one taken in this commit instead.
* fix compilation of no-gc builds
* review feedback
0 commit comments