Open JamesDunne opened 1 year ago
Hi @JamesDunne, you are right. What WAMR does now is more like a "launch" rather than an "attach" in VS Code debug. And it's not something very common in remote debugging.
Would you say it's a good idea to provide the "attach" option for the debugger? Maybe use a command line option to control whether to stop the wasm program at the entry.
I found a way to work around it by doing wasm_debug_instance_create
followed by wasm_cluster_thread_continue
. This lets the debugger thread listen for a connection in the background while running the wasm code. It didn't work using the debug api to continue since that broke the state machine.
I'm not using iwasm from the command line but rather a custom embedding so command line option is irrelevant to me but that solution sounds reasonable.
I am glad that you find the workaround, but it sounds like you still can't use it as you want.
For custom embedding, maybe we can add an API, to set the stop-at-entry behavior for the debug instance. I am thinking this API should be called before creating the debug instance. I will investigate this and will keep you updated.
With WAMR-1.2.2 embedded into a custom host, when I call
wasm_debug_instance_continue
immediately afterwasm_runtime_start_debug_instance
to have the wasm continue execution, lldb fails to connect and can't break the running wasm code. If I don't callwasm_debug_instance_continue
then I get no wasm execution until lldb connects, which takes several seconds and won't always occur. I don't always want to be forced to connect lldb to my host process in order to execute the wasm code normally. This is counterintuitive to traditional remote debugging where the code runs normally until the debugger attaches and issues a break.