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: Using reverse execution


Stan Shebs <shebs@apple.com> writes:

> So I'm not questioning the value of the feature, but trying to get a
> sense of the user requirements.

Well, here are some comments based on how I use gdb.


First, debugging a program with which I am not familiar, in order to
locate a bug.  Let's assume this is a reproducible bug.  The first job
is to find out where the bug is occurring.  Reverse execution can help
here with one of the examples that Stan gave.  When I 'next' over a
function, the bug might occur there.  It would be convenient to be
able to reverse over the function, and then step into it.

In order to make that work most conveniently, it would be ideal if
network and file input were replayed when going forward again.
Basically, any invocation of the read system call would ideally return
the same results as before.  Similarly for the open, socket, and
accept system calls and for system calls like ioctl (FIONREAD).  For
super extra credit, SIGIO and SIGURG signals would be repeated at the
same time as before.

For my purposes it's not necessary to replay network and file output.
In fact, in some cases that would actually be less helpful.  It would
be better to just skip the output system calls.  To put it another
way, it's not necessary for my purposes to undo any system actions
when stepping backward; it's merely helpful to replay the input calls
when stepping forward again.

Mind you, reverse execution would be useful even without the ability
to replay system calls.  It's just that it would be more useful if
they could be replayed.


Second, once the bug has been located, how did it happen?  When this
is not obvious, it's generally an issue of memory corruption or
mysterious data structure manipulation.  For this the most useful
feature would be a reverse watchpoint, to walk backward to the point
where the data was changed.  Here again it is not necessary to undo
system calls.  I should note that this would only be useful if the
reverse watchpoint were quite efficient; I don't know how feasible
that is.  I recall that non-hardware watchpoints were unusable.


Third, a different scenario, the bug which can not be recreated at
will.  gdb isn't normally too helpful on these cases, but let's say
for the sake of argument that we have a core dump or we can attach to
a running process which shows the bug.  Here again reverse execution
could be helpful to pin down where the bug happened.  However, it's
hard for me to imagine this actually getting implemented, so I won't
discuss it in detail.


Hope this helps.

Ian


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