Example - say the user wants to go back to the beginning of time, but
didn't think to take a bookmark when they were there. Executing
backwards might take a long time. For systems like Simics, UndoDB and
VMware that use a snapshot-and-replay technique it can be almost instant
to jump back to time 0. We could always add a special command to goto
time 0 or a special bookmark, but why not generalise it? e.g. maybe the
user wants to skip forwards a few seconds' worth, but again, doesn't
have a bookmark conveniently placed.
It seems that for at least some targets this would be pretty
straightforward to implement and a very useful feature for users.
I agree with this, and I think that a notion of scalar time in some undefined
unit would make the UI on the gdb side much easier. Problem is that gdb
currently lacks a time concept... and my understanding is that introducing it is
going to be painful. Time really becomes very pervasive once you start using it
in one place...
So, currently, a bookmarks mechanism seems to make the most sense. I think that
most of the issues we have can be solved at the user-level:
* Always take a bookmark when you start (which normally for is not time zero,
but rather some arbitrary point in time of the target system when the reverse is
turned on).
* Allows the backend to push bookmarks. In that way, you just set up a script or
module that sends bookmarks to gdb at a regular pace in target time (say every 1
microsecond on the target side or whatever).
* Your frontend scripts can then rely on these bookmarks.
Not super-solid, but it works with a simple bookmark mechanism and keeps time
internal to the backend.