This is the mail archive of the gdb-patches@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: GDB record patch 0.1.3.1 for GDB-6.8 release


On Wed, 2008-05-21 at 16:54 +0800, Tea wrote:

> 
> > - A question: if you record changes, then reverse GDB through them but
> >  stop it half-way, and then set the direction (gear? :-) ) back to
> >  forward, GDB will just play back the changes it has recorded, and not
> >  continue the inferior until it reaches the end of the record list,
> >  right?
> >
> 
> Yes, it's right.
> 
> >  If so this means that if the user goes back a few insns, modifies a
> >  variable which is used in an if condition, the code will still appear
> >  to take the branch it took before. This is unintuitive and may lead
> >  the inferior to an undefined state, impossible to achieve by regular
> >  runs of the program. So I think GDB either needs to be put in a
> >  "read-only" mode where it refuses to change inferior memory and
> >  registers, or it needs to discard the records made after the point
> >  where the change in inferior state was made. What do you think?
> >
> I think this is a bug of record. I will fix it.

Once you get into the idea of going backward, you soon reach
the idea of forking or branching -- taking a different route
forward than you did originally.

For an early implementation of reverse debugging, it would
be fair to simply prohibit this -- don't let gdb change the
machine state until you exit replay mode.

If you want to get fancier, you could say that if the user
does anything to change the recorded machine state, you
automatically cancel replay mode and resume debugging a "live"
machine from the new, changed state.

If you want to improve on that a little bit more, you might
say "If you change the machine state in the middle of a 
replay, I will throw away all of the recorded state *forward*
of that point, but keep the recorded state going *back* from 
there.  You can't go back into what used to be the "future"
because by changing the past, you have now destroyed that
particular future.  But you can still go further into the
past.




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