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:
That's why an abstract bookmark concept is so appealing: it can hide
anything
in
the backend, and let it worry about setting up times on multiple processors,
multiple machines, or hardware recorders.
Ok, yes, I see what you're getting at here: bookmarks might be more
easily implemented in some targets than some global linear notion of
time.

Not quite... but it lets us get some use out of time in gdb without introducing a time concept. As I said, if we let the backend generate bookmarks, we can get to any time precision we want by pushing bookmarks from the backend. Withtout gdb having to understnad time.

Ah, the discussion comes back to where we started :)


Sincere apologies if I'm being stupid here, but I'm still struggling to
understand you.  i.e. I still don't understand why "get-time/set-time"
commands require that gdb gains any notion of time.

You mentioned earlier that a target might want routinely to generate
bookmarks (e.g. every 10ms).  If that target numbered those bookmarks
1,2,3,4,etc then it would have exactly the notion of time that I'm
asking for here.


Another issue with time is that once gdb knows about time, you have to be much more careful when changing place in the program. If jumping back and forth, you have to make sure that gdb time is correctly updated. Today, having a state-less debugger makes this easier: we retrofitted (as I guess you did) reverse execution on gdb quite easily since gdb had no notion of time. Had there been that, it would have been much more painful.

I don't follow. If we had "get-time/set-time" commands, these could be proxied by gdb straight to the target. Thus gdb remains stateless in this regard, and blissfully unaware of any notion of jumping around in time. All gdb needs to know is that "set-time" will change the target's state, but that's no different to regular continue or step.

Again, you could go a lot further than I'm proposing right now.  But
that's not to say you need to for this stuff be useful.
Yes, for us, a 64-bit integer count of time would be quite useful as a
general
tool.
Cool - so is the general agreement that a scalar notion of time is a
useful thing to add, even if it's not supported in all reversible
targets?  (And bookmarks is an (at least) equally useful notion.)

I think a scalar time is very useful. But I fear that implementing it will meet with resistance and require quite drastic changes. Bookmarks are probably easier to introduce as a first step. That was what Michael Snyder said, and I can agree with that.

Hopefully Michael can clarify, but I thought he was agreeing that we don't want to teach gdb about the concept of time (not yet anyway), which I also totally agree with.

My proposal is that a "timestamp" (i.e. what "get-time" returns) would
be very like a "bookmark", except:

(a) not precise like a bookmark (e.g. if "get-time" returns timestamp X,
then a subsequent "set-time" will take you close to time X, but not
necessarily exactly at time X)

(b) multiple timestamps can be compared to get an approximate idea of
their point in history relative to each other.  e.g. timestamp 20 would
come before 22 and 22 would come before 100, and also 22 is is much
closer to 20 than it is to 100.


Ideally, I DO want gdb to be time-aware, but that does require a lot of semantic thinking for how time can and should interact with multiple threads, processor cores, and reverse debug systems.

Note my emphasis on "user" above - I'm not talking about gdb making any semantic interpretation of the timestamp. It's just a number that gdb displays to the user. Opaque to gdb, but potentially meaningful to the user.

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]