RE: Simics & reverse execution

["Jakob Engblom" <jakob@virtutech.com>]

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

I think that is safe... but Michael Snyder was very clear that this had some
major issues as I understood it? 
 
> 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.

Yes, but it is done without any time representation at the gdb side of things. 

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

Yes, but it does invite for time to become more part of the state. 

Note that I am all for this, but I can see how it quickly degenerates into a
major design issue with 

""get-time -thread x" ... how is THAT done?" ... etc ...
 
> 
> 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.

OK. All on the same plate. 
 
> 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)

Interesting idea to make this fuzzy. I can see a problem with this: unless your
backend has its own UI where you CAN check the precise time, this invites user
confusion. I often find myself carefully stepping back and forth very precise
cycle counts to observer what is going on... and this fuzzy time would not let
me do that.  It also means that when execution stops after a "set-time" command,
you really don't know where you are :)
 

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47   
Drottningholmsvägen 22      Mobile: +46 709 242 646  
11243 Stockholm             Web:    www.virtutech.com 
Sweden
________________________________________________________
  

/jakob