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.
Enough of this has fallen out of my head that I'm not sure I can usefully comment here. @tromey (an actual GDB developer) had some thoughts on this, see #26 for example.
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.