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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: