On Mon, 17 May 2021 at 18:37, Alex Bennée <alex.ben...@linaro.org> wrote: > Luis Machado <luis.mach...@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
