Trait gdbstub::stub::run_blocking::BlockingEventLoop

pub trait BlockingEventLoop {
    type Target: Target;
    type Connection: ConnectionExt;
    type StopReason: IntoStopReason<Self::Target>;

    // Required methods
    fn wait_for_stop_reason(
        target: &mut Self::Target,
        conn: &mut Self::Connection
    ) -> Result<Event<Self::StopReason>, WaitForStopReasonError<<Self::Target as Target>::Error, <Self::Connection as Connection>::Error>>;
    fn on_interrupt(
        target: &mut Self::Target
    ) -> Result<Option<Self::StopReason>, <Self::Target as Target>::Error>;
}

A set of user-provided methods required to run a GDB debugging session using the GdbStub::run_blocking method.

Reminder: to use gdbstub in a non-blocking manner (e.g: via async/await, unix polling, from an interrupt handler, etc…) you will need to interface with the GdbStubStateMachine API directly.

Required Associated Types

type Target: Target

The Target being driven.

type Connection: ConnectionExt

Connection being used to drive the target.

type StopReason: IntoStopReason<Self::Target>

Which variant of the StopReason type should be used. Single threaded targets should use SingleThreadStopReason, whereas multi threaded targets should use MultiThreadStopReason.

Required Methods

fn wait_for_stop_reason( target: &mut Self::Target, conn: &mut Self::Connection ) -> Result<Event<Self::StopReason>, WaitForStopReasonError<<Self::Target as Target>::Error, <Self::Connection as Connection>::Error>>

Invoked immediately after the target’s resume method has been called. The implementation should block until either the target reports a stop reason, or if new data was sent over the connection.

The specific mechanism to “select” between these two events is implementation specific. Some examples might include: epoll, select! across multiple event channels, periodic polling, etc…

fn on_interrupt( target: &mut Self::Target ) -> Result<Option<Self::StopReason>, <Self::Target as Target>::Error>

Invoked when the GDB client sends a Ctrl-C interrupt.

Depending on how the target is implemented, it may or may not make sense to immediately return a stop reason as part of handling the Ctrl-C interrupt. e.g: in some cases, it may be better to send the target a signal upon receiving a Ctrl-C interrupt without immediately sending a stop reason, and instead deferring the stop reason to some later point in the target’s execution.

Suggestion: If you’re unsure which stop reason to report, BaseStopReason::Signal(Signal::SIGINT) is a sensible default.

Implementors