[RFC/WIP] GDB support for replay diversions

[Bob131]

I've been thinking about some of the awkwardness that currently exists around diversions: scheduling issues touched on in #2840, hidden state confusing GDB (e.g. #2867) and users (e.g. #1968) and the hacks and heuristics involved in trying to determine when diversion sessions should be set up/torn down. These problems aren't intractable, but it seems like they'll continue to crop up until GDB gains explicit support for a notion similar to that of rr's diversion session.

This patchset implements a (yet to be) proposed extension to the GDB remote protocol that would move control over diversion state out of rr and into GDB. The protocol introduces a new protocol feature and packet: vReplayDiversion. GDB can send vReplayDiversion:1 to request a switch to a diversion session, and vReplayDiversion:0 to end a diversion session. rr may additionally notify GDB of a premature diversion session exit by sending an inferior-exit stop packet. The GDB-side implementation mimics rr's logic (vReplayDiversion:1 on inferior call, vReplayDiversion:0 on continue) but could have commands like replay-diversion {enter,exit} in the future.

I've not yet submitted my proposal to the GDB mailing list; it seemed like a good idea to solicit feedback from the rr developers first, to make sure the approach is considered appropriate on the rr side. Given that I don't know if any such proposal will be accepted for GDB or how much any accepted proposal may differ from above, I've submitted this as a draft PR for the time being.

Potential future directions

I'm also interested in feedback on the following ideas. I understand a discussion on these may be out of scope for this PR; let me know if you'd prefer separate issue(s).

• Expose seeking/checkpoints/bookmarks: GDB has bits of support for these (seeking and bookmarks likely just need remote protocol extensions, and the core is checkpoint-aware). This would eliminate the need for about half of GdbCommand.cc, allow (eventual?) removal of some of the GDB macros and hopefully bring a more consistent interface.
• info replay: Replace elapsed-time, when, when-ticks and when-tid with an info replay subcommand. Strictly speaking, this doesn't need support from GDB, but it would be a good complement to GDB's info record subcommand and GDB support would make it an interface consistent with other (hypothetical) GDB targets.

[rocallahan]

vReplayDiversion seems like a good idea, if the GDB developers are receptive. We will need GDB commands to explicitly enter and exit diversions, at least for our tests.

let me know if you'd prefer separate issue(s).

Those sound good too but yes, please make them separate issues.

[GitMensch]

I've not yet submitted my proposal to the GDB mailing list

@Bob131 Was there a proposal sent to [email protected]? I did not found any mention of vReplayDiversion there yet, but also think your approach is a good idea.

[Bob131]

On Wed, Mar 16, 2022 at 09:45:55 -0700, Simon Sobisch wrote:

@Bob131 Was there a proposal sent to @.@.)?

There was indeed; see https://sourceware.org/pipermail/gdb-patches/2021-June/179432.html. I never got much in the way of feedback, though, and ultimately forgot about it.