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


> > going to be painful.  Time really becomes very pervasive once you start
using
> it
> > in one place...
> 
> Intriguing.  In what ways?
> 
> We currently have a somewhat baroque bunch of python that wraps up gdb
> to enable our reverse debugging commands on users system where they've
> an older version of gdb installed.  This includes some commands to
> display the current time and jump to an arbitrary time (where time is a
> scalar 64-bit integer).  The rest of gdb remains blissfully unaware
> (obviously, since it's unpatched).
> 
> I can see how in general "teaching" the concept of time to gdb would be
> a huge job.  But I don't think a command to jump around arbitrarily and
> another to display the "current" time needs to teach anything about time
> to the rest of gdb.

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? 

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). 
 
Also, how should this interact with non-stop debug? And how should you handle
multiple active processor cores running parallel threads? 

> > So, currently, a bookmarks mechanism seems to make the most sense. I think
that
> > most of the issues we have can be solved at the user-level:
> >
> > * Always take a bookmark when you start (which normally for is not time
zero,
> > but rather some arbitrary point in time of the target system when the
reverse
> is
> > turned on).
> >
> > * Allows the backend to push bookmarks. In that way, you just set up a
script
> or
> > module that sends bookmarks to gdb at a regular pace in target time (say
every
> 1
> > microsecond on the target side or whatever).
> >
> > * Your frontend scripts can then rely on these bookmarks.
> >
> > Not super-solid, but it works with a simple bookmark mechanism and keeps
time
> > internal to the backend.
> 
> All of the above sounds good to me.
> 
> However, I still reckon a pair or commands simply to get and set the
> time as a scalar value should be both useful for the user, and  trivial
> to implement (he said, confidently :-)  It could be orthogonal to
> bookmarks (a way to convert bookmarks to scalar time value would be
> useful, but not essential to start with).
> 
> We should probably pipe up with some patches, but I'm just slightly
> nervous that I may have missed something, especially as I'm not really
> terribly au fait with gdb's internals and its assumptions (hence the
> discussion first).

Me neither...

/jakob


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