[RFC] Integration with GDB checkpoints/bookmarks

[Bob131]

(Split out from #2877)

GDB has varying degrees of support for checkpoints and bookmarks:

• Checkpoints are currently specific to the linux-nat target and implemented using fork(). The semantics are quite similar to rr checkpoints, being implemented in a similar way. A notable difference, however, is that an inferior exit from the linux-nat target will transparently revert the inferior state to the last checkpoint.
• Bookmarks are part of GDB's target-generic reverse execution/debugging support. The target is expected to be able to provide an opaque byte buffer representing a particular point of execution that can be revisited at a later point. This seems fit ReplayTimeline marks quite neatly.

What combination of these makes sense for rr? Personally, I quite like keeping checkpoints more-or-less as they are and using lighter-weight rr proto-marks for GDB bookmarks, but I have trouble finding a compelling rationale for having both (beyond my desire to have an interface for proto-marks usable from GDB scripts); any meaning assigned to one relative to the other will probably be rather arbitrary.

Additionally, is fleshing out GDB's support for target-generic (and remote) checkpoints worth much to rr? The main benefits seem to be interface consistency and the potential to shed some hacks from rr, but bookmarks (in some form) may well be better for interface consistency and shedding hacks won't really be an option until there's almost no-one using rr with GDB <11/12/13/whenever.

[rocallahan]

Where are bookmarks documented? All the gdb documentation I can find treats "bookmarks" as meaning the same thing as "checkpoints".

[Bob131]

Hmm, it actually appears as though it isn't. My description comes from the GDB sources: gdb/target.h for target_{get,goto}_bookmark, gdb/reverse.c for the implementation of the commands, and gdb/record-full.c for the only implementation of the target interface so far.

[rocallahan]

Hmm, it actually appears as though it isn't

Are you saying "bookmarks aren't the same as checkpoints" or "bookmarks are the same as checkpoints"?

If they're not the same as checkpoints, what do users do that triggers the creation of a bookmark?

[Bob131]

Sorry, I meant to say "it actually appears as though bookmarks aren't documented"; bookmarks are a different mechanism. They can be created with the bookmark command, used with goto-bookmark, listed with info bookmarks and removed with delete bookmark.

[rocallahan]

That seems exactly like checkpoints from the user's point of view.

So I would like to know: why has GDB exposed bookmarks and checkpoints as separate features? How do GDB developers expect users to use checkpoints and bookmarks differently?

[Bob131]

I can't speak on their behalf, but having a look at the discussions around the relevant patchsets (checkpoints and bookmarks) on the mailing list it seems as though the mechanisms have/had different intentions. Checkpoints (at least as originally proposed and implemented) were explicitly about process forks and pre-dates GDB's multiprocess support; it gradually evolved to its more current, more abstracted state. Bookmarks were designed specifically for the case of trace replay (by the same person, no less!) and have a replay-specific feature that checkpoints don't: the bookmark command optionally takes an argument, sent verbatim to the target as a textual descriptor of a point in the trace.

As for how the usage differs, it seems as though the intention is that no target would support both: checkpoints allow one to return to an inferior existing in a particular state and manipulate it arbitrarily (and are therefore limited to live targets) whereas bookmarks allow one to visit a snapshot of an inferior's state at a particular point in time (which doesn't require a live process). None of this appears to be explicitly documented so I'm reading between the lines fairly heavily here, but it seems like a reasonable rationale given the history.

If we're splitting hairs, I would posit that what rr calls checkpoints are sort of more in the spirit of bookmarks: replay diversions make for an interesting kind of hybrid, but ultimately the user is still limited to the recorded trace. Of course, a textual representation of a mark with greater resolution than an (event,ticks) pair is not really practical.

[rocallahan]

OK. I think GDB's UI choices leave something to be desired here --- as always --- but I guess I'd be fine with supporting GDB bookmarks via rr Marks or ProtoMarks.