Hi @luser,
I'm working on a similar project for JS:
https://github.com/nomtats/gdbserver-stub
https://medium.com/@tatsuo.nomura/implement-gdb-remote-debug-protocol-stub-from-scratch-6-1ac945e57399
I implemented continuation handling by allowing the handler to return "OK" and keep executing.
The handler emits an "stopped" even at a breakpoint or when received a Ctrl-C.
In rust-gdb-remote-protocol, IIUC, handle_continue needs to return a stop reason, which might not be possible before the connection goes timeout in NoAck mode because GDB/LLDB expects a immediate reply from the stub.
I can cheat by replying a stop to GDB while continue executing, but I wonder if there is a better way to properly do this.
Hi @luser,
I'm working on a similar project for JS:
https://github.com/nomtats/gdbserver-stub
https://medium.com/@tatsuo.nomura/implement-gdb-remote-debug-protocol-stub-from-scratch-6-1ac945e57399
I implemented continuation handling by allowing the handler to return "OK" and keep executing.
The handler emits an "stopped" even at a breakpoint or when received a Ctrl-C.
In rust-gdb-remote-protocol, IIUC, handle_continue needs to return a stop reason, which might not be possible before the connection goes timeout in NoAck mode because GDB/LLDB expects a immediate reply from the stub.
I can cheat by replying a stop to GDB while continue executing, but I wonder if there is a better way to properly do this.