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
Motivation
In order to make SwiftWasm more debuggable a SwiftWasm REPL is needed. This would also be very helpful for debug tools. Solution
My Idea to make this happen with as little effort as possible for the swiftwasm maintainers while still having the maximum of flexibility for debugging tools is the following:
prerequisit: there is a paused (dummy or real) SwiftWasm main module inside of a wasm runtime xy
A REPL prompt text is submitted
analyse the current callframe of the main module and extract variable names and their pointers from DWARF
swift codegen: wrap REPL prompt in a exported function with raw pointers to all reachable variables as function parameters
compile the wrapped REPL prompt with SwiftWASM into a new wasm module. Lets call it "side module"
load side module into runtime
import WebAssembly.Memory from paused main module into the compiled side module
call the exported generated repl wrapper function from side module and pass pointers of the reachable variables into the function
add newly declared variables (found by dwarf in generated side module) to some kind of REPL session
go back to step 0
Im currently blocked by step 5: importing a external WebAssembly.Memory into a Module compiled by SwiftWasm
I'm having problems with runtime initialization of the sidemodule crashing.
Whats needed
What I need to proceed is something similar to emscripten side modules.
Ideally theres also no swift runtime linked inside of a side module to improve performance by reducing parsing time and no call to the runtime initialization, which would f*** up the state of the runtime of the main module.
Questions
Are there already flags to avoid linking everything?
Can someone explain what happens inside __wasm_call_ctors?
This is the first successful dump of a nested struct from a "sidemodule".
However, I need something like AssemblyScripts --memoryBase linker flag in order to proceed with my hacky prototype.
The text was updated successfully, but these errors were encountered:
Motivation
In order to make SwiftWasm more debuggable a SwiftWasm REPL is needed. This would also be very helpful for debug tools.
Solution
My Idea to make this happen with as little effort as possible for the swiftwasm maintainers while still having the maximum of flexibility for debugging tools is the following:
prerequisit: there is a paused (dummy or real) SwiftWasm main module inside of a wasm runtime xy
Im currently blocked by step 5: importing a external WebAssembly.Memory into a Module compiled by SwiftWasmI'm having problems with runtime initialization of the sidemodule crashing.
Whats needed
What I need to proceed is something similar to emscripten side modules.
Ideally theres also no swift runtime linked inside of a side module to improve performance by reducing parsing time and no call to the runtime initialization, which would f*** up the state of the runtime of the main module.
Questions
Are there already flags to avoid linking everything?
Can someone explain what happens inside __wasm_call_ctors?
Update
step 5 is not an issue anymore
This is the first successful dump of a nested struct from a "sidemodule".
However, I need something like AssemblyScripts --memoryBase linker flag in order to proceed with my hacky prototype.
The text was updated successfully, but these errors were encountered: