Jonas Minnberg
Jonas Minnberg
The type can be called something else. The important part is that it is _opaque_ to AssembyScript. It should not assume anything about it, and should only be allowed to...
Well I would probably need to store it. Thinking more about it I guess the clearest would maybe be a type `opaque_ptr`, that is stored as a u64 or u32...
I think I just wasn't clear on my use case. I don't care about pointers/memory in web assembly space at all. I create objects on the native side and just...
The size of pointers on the host matters only because I need to store them in the correct sized type on the WASM side, and make sure they are passed...
The problem is that a native function `void hey(void* ptr)` will need a different signature depending on the host. I would have to wrap all functions that takes pointers like;...
As mentioned above I will probably eventually want to store it, so I don't want to use that.
No, it will be our own code, and will be signed as well - so this is mostly to guard against programming errors. So we can live with the current...
Homebrew python 3.10.6, so I guess that's it. Do you know of a work-around?
NOTE: Calling `wasm_runtime_dump_call_stack(env)` from the native function does nothing since at that point `module->frames` is empty... (wasm code built with debug, stack trace enabled, classic interpreter)
Not sure how to get the relevant info from the frame - there is an `ip` ptr that I can maybe use if I know the start of the memory...