I realized that I needed to get shared memory working before I could get the spec tests to pass. Do you have any pointers @Saúl Cabrera ?
While debugging, I found this function: https://github.com/bytecodealliance/wasmtime/blob/main/crates/environ/src/module.rs#L456-L473
But it find it fishy: If there is only a single shared memory in the module, this function returns 0, which seems incorrect, since we get an offset to an unexisting owned memory
IIRC "owned" here is defined-and-not-shared, so if a shared memory gets an owned index I think that's a bug?
sounds like a bug to me too
I believe you'd need to handle the shared memory here: https://github.com/bytecodealliance/wasmtime/blob/main/winch/codegen/src/codegen/env.rs#L250
how are owned memories laid out in the vm context? are all owned memoried contiguous? what's at index 0? because even it there's a single owned memory, this function would return 1, but I would assume that the first owned memory would be at offset 0 :thinking:
it looks like this in the vmcontext
@Saúl Cabrera yes, that how I got to the linked function
where do shared memories live?
here: https://github.com/bytecodealliance/wasmtime/blob/de1ad347e34f00d3c10959ff14460e90b44f7907/crates/environ/src/vmoffsets.rs#L28? @Alex Crichton
yes all memories should live in that memories
field, and for owned-and-not-shared memories those are self-pointers to the owned_memories
field
for shared memories the memories
field should point to within the shared memory itself
@marin The Memory
entry in HeapData
has a shared
field, to help you determine if it's shared or not. Here's how that case is handled in Cranelift: https://github.com/bytecodealliance/wasmtime/blob/de1ad347e34f00d3c10959ff14460e90b44f7907/crates/cranelift/src/func_environ.rs#L2323
Thanks @Saúl Cabrera, that's what I was looking for :thumbs_up:
alright, got it to work, all the tests are passing now. Thanks :salute:
Last updated: Jan 24 2025 at 00:11 UTC