Re: Best approach for supporting snapshots for QEMU's gdbstub?

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 17 May 2021 at 18:37, Alex Bennée <alex.bennee@linaro.org> wrote:
> Luis Machado <luis.machado@linaro.org> writes:
> > Right. We don't support reverse step/next/continue for remote targets.
> > I think this would be the most appropriate way to implement this
> > feature in GDB. But it is not trivial.
>
> You do because ";ReverseStep+;ReverseContinue+" is part of the gdbstub
> negotiation handshake.
>
> Out of interest how is rr implemented? It presents a gdb interface so I
> thought it was some implemented using some remote magic.

AIUI rr just implements the reverse-step/reverse-continue parts
of the gdb remote protocol. It makes them fast by internally to
its implementation saying "ah, you wanted to do a reverse-step,
I can do that by starting from the best available checkpoint and
going forwards" and by automatically creating checkpoints at
points that it thinks will be useful. gdb and the remote protocol
know nothing about these checkpoints -- they are purely created and
managed under the hood by rr as an optimisation so that reverse-step
is decently fast. (Given that it's the rr end that knows best about
what checkpoints  are available, how expensive it is to create a
checkpoint, etc, that seems not unreasonable.)

There are also a handful of rr-specific gdb commands kind of
like the QEMU-specific ones, which the user can use to say
things like "go directly to this point in time T" which the
gdb UI doesn't have a concept of. (Also because rr starts the
gdb for you it gets a chance to feed it a few gdb macro
definitions which I think mostly just make the debugging
experience a bit smoother rather than being critical parts
of the gdb-to-stub communication.)

thanks
-- PMM