search

luser / rust-gdb-remote-protocol

A Rust crate implementing the GDB Remote Serial Protocol
Apache License 2.0
33 stars 13 forks source link

Support non-stop #26

Open tromey opened 6 years ago

tromey commented 6 years ago

In non-stop mode, the client just replies OK to commands like vCont, and then generates an async notification packet when there is some noteworthy inferior event.

This means that the client would have to have some way to tell process_packets_from that an event like this occurred.

luser commented 6 years ago

If we're going to wind up having async behavior then we'll either need to split networking and the handler into separate threads and use std::sync::mpsc::{Sender, Receiver} to multiplex messages from both threads to a single place, or go all-in and use tokio and Future.

tromey commented 6 years ago

The server can also send output to gdb while gdb is waiting for a stop reply -- the O packet. In the sync model this would be a callback from a handler back into the I/O loop.

I think it would be best if this code were just always async and then sometimes pretended to be sync for the protocol's sake.

tromey commented 6 years ago

If the server code were always async, then I think QNonStop would be handled entirely by this library and not require a Handler method.

tromey commented 6 years ago

See https://github.com/tromey/rust-gdb-remote-protocol/tree/multi-threaded for a draft of how this could work. So far that just implements the threading bits: the reading is done in one thread, and the handlers and response writing are done in whichever thread called process_packets_from.

After this the idea would be that target-continuing functions (whatever Handler method we call to implement vCont) would get an object which implements Write and which also has some sort of stopped method.

The Write implementation in all-stop would send O packets, but in non-stop would just drop the output (since this isn't defined for non-stop yet)

The stopped method would take a StopReason and would simply post it to the channel, so that the command processor would send it on to the client. Maybe we could make this a bit safer by making each such object single-use, and requiring them to appear in order. That way the server couldn't re-send a stop reason or send stop reasons out of order somehow.

tromey commented 6 years ago

Maybe we could make this a bit safer by making each such object single-use

Actually they can't be single use in non-stop mode. And, in all-stop mode, it's expected that any stop will stop all threads -- so this information has to be exposed.

See https://github.com/tromey/rust-gdb-remote-protocol/tree/client-state for some more work in this area.

Also the % notification / vStopped processing will require a bit more state, namely a vector of pending stops and also a flag indicating whether the initial notification has been sent.