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
Rewrite GdbStub::run to use the state machine implementation (and more!) (#88)
This is a set of API changes I've been sitting on for many months now, and I think it's high-time that I pushed these changes up.
The docs are still a mess, but I've opted to commit things as is to get hands-on feedback from folks to make sure things work, and then I'll tackle the documentation later.
At a high level, this PR introduces the following API tweaks:
#### Removed the `read` and `peek` methods from `Connection`, moving them into a separate `ConnectionExt` trait.
The state machine API was explicitly designed to _circumvent_ the need for a blocking `read` API. Nonetheless, it is useful to have a reference implementation of a blocking single-byte read for various types (e.g: TcpStream) built-in to `gdbstub`, so I've split these implementations off into a separate `ConnectionExt` trait - which as the name implies, requires the type to also implement `Connection`. This new trait is used as part of the `GdbStub::run_blocking` API described below...
#### `Target::resume` is now _non blocking_, and does not support immediately returning a `StopReason`
The previous iteration of the API kept the ability to return a `StopReason` from `Target::resume` in order to maintain compatibility with existing blocking `Target::resume` implementations (such as the one in the `armv4t` example).
With this new API, targets are now _forced_ to resume in a non-blocking manner, with the responsibility of "driving" the resumed target lifted up into the state machine event loop.
This change also means that `Target::resume` no longer takes a `GdbInterrupt` callback, which has simplified a _ton_ of code within `gdbstub`!
#### The bespoke blocking `GdbStub::run` implementation has been swapped out with a new `GdbStub::run_blocking` method - backed by the state machine API.
Instead of maintaining two parallel "front-ends" to `GdbStub`, I've consolidated the two to both use the `GdbStubStateMachine` API under the hood. This new API is _looks_ more complex to the old `GdbStub::run` API, as it requires the user to provide an implementation of `gdbstub_run_blocking::BlockingEventLoop` for their particular `Target` + `Connection`, but in reality, all this new API has done is "lift" most of the code that used to live in `Target::resume` up into `gdbstub_run_blocking::BlockingEventLoop`.
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ Why use `gdbstub`?
28
28
-**`#![no_std]` Ready & Size Optimized**
29
29
-`gdbstub` is a **`no_std` first** library, whereby all protocol features are required to be `no_std` compatible.
30
30
-`gdbstub` does not require _any_ dynamic memory allocation, and can be configured to use fixed-size, pre-allocated buffers. This enables `gdbstub` to be used on even the most resource constrained, no-[`alloc`](https://doc.rust-lang.org/alloc/) platforms.
31
-
-`gdbstub` is entirely **panic free** (when compiled in release mode, without the `paranoid_unsafe` cargo feature).
31
+
-`gdbstub` is entirely **panic free**in most minimal configurations (when compiled in release mode, without the `paranoid_unsafe` cargo feature).
32
32
- Validated by inspecting the asm output of the in-tree `example_no_std`.
33
33
-`gdbstub` is transport-layer agnostic, and uses a basic [`Connection`](https://docs.rs/gdbstub/latest/gdbstub/trait.Connection.html) interface to communicate with the GDB server. As long as target has some method of performing in-order, serial, byte-wise I/O (e.g: putchar/getchar over UART), it's possible to run `gdbstub` on it!
34
34
- "You don't pay for what you don't use": All code related to parsing/handling protocol extensions is guaranteed to be dead-code-eliminated from an optimized binary if left unimplemented! See the [Zero-overhead Protocol Extensions](#zero-overhead-protocol-extensions) section below for more details.
0 commit comments