This is the mail archive of the gdb@sources.redhat.com 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: [discuss] Support for reverse-execution


> Date: Sat, 21 May 2005 10:19:31 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com
> 
> One, it requires extensive additional support from the target.  State
> is huge and complicated - multiple threads, file system operations,
> network packets.  You need a target that supports checkpointing to do
> this.  I'm told there are native platforms which could offer this - I
> just don't know what any of them are.

Well, at least the Linux kernel developers could perhaps be persuaded
to add such a support.

> Two, this is basically the same thing as the bookmarking feature
> already proposed in this thread; just have GDB automatically take a
> bookmark at every stop.

Correct.  What I'm saying is that by adding this we would provide a
large part of user-level functionality that is served by the full set
of reverse-* commands, but with the advantages that:

  (a) the list of new commands is much smaller and thus simpler
  (b) we don't need to figure out the right semantics of tricky
      commands like "reverse-next" and "reverse-finish"
  (c) part of the implementation is on the GDB side (as opoosed to the
      target side), so it will be easier to enable it for more targets

> > If we implement something like that, perhaps we could ditch all the
> > reverse-* commands whose names we are discussing at such length in
> > this thread, and instead implement only one command, called, say,
> > "rewind" or "backup" or some such.  That, and a set/show mode command
> > to enable checkpointing would be enough, I think, to have 99% of the
> > functionality originally suggested in this thread.
> 
> Not at all.  Here's a big use of reversible debugging: timing-sensitive
> or otherwise very hard-to-reproduce problems.  You want to be able to
> leave the program running, hooked up to a simulator and a debugger, and
> then once the mysterious bug has occurred back up a little bit to see
> why.

Okay so perhaps it's less than 99%, but it's still a large portion.


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