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
Per a discussion, following options are available for enabling breakpoints in WasmKit:
> One of the main difficulties in implementing breakpoint in WasmKit is that our internal instruction set is not a 1:1 map of Wasm instruction set, unlike IPInt in JSC. Therefore, we need a way to translate address between Wasm byte offset <-> internal ISeq.
>
>Option 1: Record address translation table during compiling wasm bytecode to internal ISeq when a first breakpoint is set to the function, then patch the internal ISeq to set breakpoint using the table. We only need one-time re-compilation to record the table, so later breakpoint settings will be trivial, but it adds non-trivial memory footprint to hold the table.
>
>Option 2: Patch the original wasm bytecode to replace the target instruction with a special reserved breakpoint instruction and compile to the internal ISeq. We don't need to hold the addr translation table but need to re-compile every time a new breakpoint is set.
>
> Option 3: Implement in-place interpreter along side with the current fast interpreter. This is the simplest approach and what WAMR and JSC are doing for their classic interpreter and IPInt respectively, but need to maintain two interpreters.
We've decided to proceed with Option 2, where a special `breakpoint` instruction is added to the VM, which is translated from 0xFF Wasm binary code. This code can never be supplied by the user, as it isn't enabled in the parser. In a future PR we'll provide `public` methods on module instances like `func enableBreakpoint` that flips this instruction in in-memory module source and recompiles the corresponding function to VM bytecode with the new `breakpoint` instruction.
0 commit comments