This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simics & reverse execution


Jakob Engblom wrote:
If the 64 bits of the integer were to be considered 'opaque' and no more
than a unique handle onto a point in history, that would be fine.  But
such a restriction is unfortunate, because you wouldn't be able to e.g.
binary chop history.

But on which side of the debugger connection would you do this?

I was assuming it would be driven by the gdb side. One can imagine "smart" targets that allow optimized binary chop type stuff. But it seems reasonable to assume that not all targets will have such smarts.


Most important I think is to enable the user to do the binary chop. It might not be a straight-forward thing they're looking for, and in general it would be a very useful thing for the user to be able to say, essentially, "back a bit, back a bit more, forward a bit".

For that to work we need some way for gdb to know about and be able to control a point in history relative to other points in history.

As I mentioned earlier, a way to convert between an opaque handle and a scalar value would allow this (this is what UndoDB does right now). An alternative take would be to enable gdb to query and set the percentage through recorded history we are right now. That is, use two interfaces: one to get/set an opaque, unique timestamp ID (used for bookmarks) and another to get/set the percentage of the way through the record log we currently are (to allow e.g. a graphical frontend to implement a slide-bar to show where in the record log we are). The former is precise to instruction count (and signals, etc); the latter may not be depending on the details of the target. Actually, percentage is the wrong term -- better would be what fraction of the way are we through history, e.g. in 1/(2^64) increments, such that half way through recorded history would be represented as 2^63.

I don't have strong opinions on exactly how the protocol should express this. But I do think we need a "precise" notion of time (e.g. for bookmarks) and a "relative" notion of time (e.g. for displaying a slide-bar in a GUI). If we're to use the same "type" to do both jobs, an 8-byte integer is a bit restrictive. If we're to use different types (probably with conversion between the two), then each being an 8-byte integer is fine.


Greg -- Greg Law, Undo Software http://undo-software.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]