RE: Simics & reverse execution

["Jakob Engblom" <jakob at virtutech dot com>]

> > Think about the cross-product with thread handling.  If you use time
> > there, you need to determine how to handle times for threads. One
> > timeline per thread? Or a global system time?
> 
> Oh right, yes, I was assuming global.
> 
> If time were per thread, then yes, I can see how that would quickly get
> very complicated.

And I think time is per-thread in process record, as that is based on
instruction counts.  Not to mention to synch time across multiple processors
which are executing in parallel... that is a very  non-trivial problem in
practice.
 
> > You also really like to have time breakpoints in the system, to
> > allow you to do things like "run this system for 6.132 seconds and
> > then stop" (typical operation we do when skipping a boot sequence or
> > we have run a workload several times and know when itneresting
> > things should start to happen).
> 
> I would argue that's a future feature.  Time-based breakpoints would
> seem a very nice thing to have, but a system which had get/set time
> commands but no time breakpoints would be a lot more more useful than
> one with neither.

True. And actually, if you "set" time to 6.132 seconds in my example, a smart
backend would do the same... execute until that point even if it was not already
executed. That's what Simics does, I think.
 
> > Also, how should this interact with non-stop debug? And how should
> > you handle multiple active processor cores running parallel threads?
> 
> I must confess, I haven't given much thought at all to the interaction
> of non-stop debug with reverse debugging in general.  I haven't been
> following too closely, but aren't they currently incompatible anyway?
> (something to do with displaced breakpoints not working well with
> reverse).  But I don't see how it's any worse than the bookmarks case.
> In fact, I don't see how any of it differs from use with bookmarks.  All
> we're really talking about is a different way to describe a point in
> history.

The problem is that different backends have different natural semantics here. 

A simulator has a natural semantic of synchronous stop across all processors,
devices, and everything else going on.  A hardware across JTAG is far more
likely to stop just a few cores and keep the rest running.  Hardware with
recording: ????

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. 

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

/jakob