Luis Machado <luis.mach...@linaro.org> writes:
> Hi, > > On 5/14/21 1:06 PM, Alex Bennée wrote: >> Hi, >> I've been playing around with QEMU's reverse debugging support which >> I have working with Pavel's latest patches for supporting virtio with >> record/replay. Once you get the right command line it works well enough >> although currently each step backwards requires replaying the entire >> execution history until you get to the right point. >> QEMU can quite easily snapshot the entire VM state so I was looking >> to >> see what the best way to integrate this would be. As far as I can tell >> there are two interfaces gdb supports: bookmarks and checkpoints. >> As far as I can tell bookmarks where added as part of GDB's reverse >> debugging support but attempting to use them from the gdbstub reports: >> (gdb) bookmark >> You can't do that when your target is `remote' >> so I guess that would need an extension to the stub protocol to >> support? >> > > 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. <snip> >> We could of course just add a custom monitor command like the >> qemu.sstep= command which could be used manually. However that would be >> a QEMU gdbstub specific approach. > > That would be an easy and quick way to allow GDB to control things in > QEMU, but I wouldn't say it is the best. Monitor commands are > basically a bypass of the RSP where GDB sends/receives commands > to/from the remote target. We have some underlying commands we can set via the monitor including: monitor info replay monitor replay_seek <N> monitor replay_break <N> > >> The other thing would be to be more intelligent on QEMU's side and >> save >> snapshots each time we hit an event, for example each time we hit a >> given breakpoint. However I do worry that might lead to snapshots >> growing quite quickly. > > GDB would need to be aware of such snapshots for them to be useful. > Otherwise GDB wouldn't be able to use them to restore state. What does GDB need to know about them? Does it include something like the icount at a particular point. I'm curious at how a break and reverse-continue is meant to work if that breakpoint is hit multiple times from the start of a run. You need to know if the last time you hit a particular breakpoint was in fact the last time before where the user was when they hit reverse-continue. > >> Any thoughts/suggestions? >> -- Alex Bennée