Re: Simics & reverse execution

[Greg Law <glaw@undo-software.com>]

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/