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


> > 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. 

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.
 
> >> 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.

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.

/jakob


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