Andreas Karlsson (Aug 25 2020 at 13:39): Andreas Karlsson (Aug 25 2020 at 13:39):Hi, I am trying to embed wasmtime (using the C API currently) and wonder how to best copy data out from linear memory. Let's say the WebAssembly calls a host function with a pointer into linear data and a length. How to safely copy that data from linear memory to the host?
Yury Delendik (Aug 25 2020 at 13:41):Host probably has access to the instance's Memory. You can find data_unchecked() slice there https://docs.rs/wasmtime/0.19.0/wasmtime/struct.Memory.html#method.data_unchecked
Andreas Karlsson (Aug 25 2020 at 13:44):So there is a single Memory object for data + stack + heap?
Yury Delendik (Aug 25 2020 at 13:45):/me does not understand the question above as it is stated
Yury Delendik (Aug 25 2020 at 13:47):Instance normally has (created or imported) memory. How wasm code is using it, depends on the compiler to wasm target.
Yury Delendik (Aug 25 2020 at 13:47):Wasm call stack is not exposed, but can be traced via Trap structure
Andreas Karlsson (Aug 25 2020 at 13:52):Maybe it is me who is not understanding WASM but my understanding was that WASM has a memory section and a data section and that both of these will reside in linear memory. Are both of those located in the same Memory object?
Yury Delendik (Aug 25 2020 at 13:54):yeah, during instantiation engine constructs Memory based on memory and data sections.
Andreas Karlsson (Aug 25 2020 at 13:56):Gotcha. And stack is separate and not meant to be accessible to the host? At least not for passing data from wasmtime to host functions.
Yury Delendik (Aug 25 2020 at 13:57):now define "stack", is it wasm call stack or "shadow" stack that was simulated by C or Rust compiler
Andreas Karlsson (Aug 25 2020 at 13:58):I think what I am talking about is the shadow stack. The one where the webassembly code could allocate values on, not the part used for tracking return addresses and restoring registers when doing function calls.
Yury Delendik (Aug 25 2020 at 14:00):okay, so if you have wasm "pointer" at the host, you can slice that from Memory's data_unchecked()
Andreas Karlsson (Aug 25 2020 at 14:08):Thanks, I need to check it out. The reason i was confused is because I saw things like "(global $__heap_base (export "__heap_base") i32 (i32.const 1049080))" in code compiled by rustc making me think that the linear memory must be non-contiguous due to the big distance from zero while the Memory documentation pages says Memory objects are contiguous.
Yury Delendik (Aug 25 2020 at 14:10):Actually, I think you are not wrong in terms of distance 0x1001F8. Look at (memory) min limit.
Yury Delendik (Aug 25 2020 at 14:11):it shall be > 0x10
Yury Delendik (Aug 25 2020 at 14:12):means, the instance reserves that much memory
Andreas Karlsson (Aug 25 2020 at 14:13):From the wasm:
(memory $memory (export "memory") 17)
(global $g0 (mut i32) (i32.const 1048576))
(global $__data_end (export "__data_end") i32 (i32.const 1049080))
(global $__heap_base (export "__heap_base") i32 (i32.const 1049080))
(elem $e0 (i32.const 1) func $_ZN3std5alloc24default_alloc_error_hook17hcb82c7fe7df69521E)
(data $d0 (i32.const 1048576) "aaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"))
yep 17 * 65536 = 0x110000
Yury Delendik (Aug 25 2020 at 14:14):rest of the memory probably goes to shadow stack
Yury Delendik (Aug 25 2020 at 14:14):(global $g0 (mut i32) (i32.const 1048576)) <-- it starts from high address = 0x100000
Andreas Karlsson (Aug 25 2020 at 14:19):Aha! That makes a lot of sense. So Rust allocates 17 pages for shadow stack? Not that much memory but enough that I need to be careful about it.
Yury Delendik (Aug 25 2020 at 14:20):16 pages, last page for data (segment)
Yury Delendik (Aug 25 2020 at 14:21):I think linker options allow to make it less (I cannot find it, but hope it is there :)
Andreas Karlsson (Aug 25 2020 at 14:22):Thanks again. This made things a lot clearer for me.
Last updated: Nov 22 2024 at 17:03 UTC