Fix least valid pointer value

[kateinoigakukun]

WebAssembly doesn't reserve low addresses But without "extra inhabitants" of
the pointer representation, runtime performance and memory footprint are
worse. So assume that compiler driver uses wasm-ld and --global-base=1024 to
reserve low 1KB.

Fix #2223

[MaxDesiatov]

👏

[MaxDesiatov]

So how come this issue wasn't reproducible in browsers, but only in Wasmer and Wasmtime?

[kateinoigakukun]

I confirmed that JavaScriptKit allocates some memories before main func. After JavaScriptKit initial allocation, heap objects are allocated at more than 4KB address, so this issue doesn't happen.

[kerimcharfi]

WebAssembly doesn't reserve low addresses But without "extra inhabitants" of the pointer representation, runtime performance and memory footprint are worse. So assume that compiler driver uses wasm-ld and --global-base=1024 to reserve low 1KB.

Fix #2223

Can you explain: "extra inhabitants" of the pointer representation? What is this low 1kb used for?

[kateinoigakukun]

Can you explain: "extra inhabitants" of the pointer representation? What is this low 1kb used for?

To distinguish enum cases without adding extra but width. Think that MemoryLayout<Optional<UnsafeRawPointer>>.size is a 32bits or 64bits value for example.

[kerimcharfi]

Thank you very much for your answer. However, I don't understand it without more context, as I have little experience in this domain.

Im trying to do this for my SwiftWasm REPL experiment:

source: https://wiki.hyperledger.org/display/iroha/WebAssembly+FFI+-+module+linking

I though I could use --global-base flag to achieve this but found it blocked.
I assumed this layout for SwiftWasm:

source: https://wiki.hyperledger.org/display/iroha/WebAssembly+FFI+-+module+linking
Is this how SwiftWasm is laid out?
Where / When does read/write happen to this lower 1KB?
Can this lower 1KB be relocated?

[kateinoigakukun]

I'm sorry, my first explanation was wrong. I updated my comment.

If you are thinking about dynamic linking, it's much more challenging than you think. The most difficult part is making a relative pointer across data and code to be position independent. See this thread for more details.

But let me answer your questions respectively just in case:

Is this how SwiftWasm is laid out?

The memory layout explained by the figure is correct only when passing --stack-first to wasm-ld. You can learn how the wasm-ld layout the memory space at link-time here: https://github.com/llvm/llvm-project/blob/1365ff74cb7d9f15feafdd4fbe2996d2f9e42a5e/lld/wasm/Writer.cpp#L330

Where / When does read/write happen to this lower 1KB?

No read/write should happen against the lower 1KB. This convention let the compiler assume that Optional<UnsafeRawPointer>.none can be represented as 0 (because a valid pointer should not be 0~1024, so we can distinguish 0 from a pointer.)

Can this lower 1KB be relocated?

What do you mean "relocated"? "Relocation" is a term that represents a process during the linking, right? I'm not sure what you are asking, sorry.

[kerimcharfi]

Thank you for your helpful answer and the link to the Wasm Support forum thread.
Are there any other uses despite nullptr destinction in the range 0~1024?
Could this theoretically be replaced with any range 0~X?
Why was 1024 chosen?