public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@airs.com>
To: Stan Shebs <shebs@apple.com>
Cc: gdb@sourceware.org
Subject: Re: Using reverse execution
Date: Fri, 16 Sep 2005 17:50:00 -0000	[thread overview]
Message-ID: <m3mzmcdhs0.fsf@gossamer.airs.com> (raw)
In-Reply-To: <432ACFFB.9040204@apple.com>

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

  parent reply	other threads:[~2005-09-16 17:50 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-13  1:17 Stan Shebs
2005-09-13  3:43 ` Eli Zaretskii
2005-09-14  0:36   ` Stan Shebs
2005-09-14  3:42     ` Eli Zaretskii
2005-09-14 22:34       ` Stan Shebs
2005-09-15  3:37         ` Eli Zaretskii
2005-09-15  5:36           ` Stan Shebs
2005-09-15 15:14             ` Eli Zaretskii
2005-09-15 18:02               ` Jason Molenda
2005-09-15 20:12                 ` Stan Shebs
2005-09-16 10:42                   ` Eli Zaretskii
2005-09-16 14:00                     ` Stan Shebs
2005-09-16 16:22                       ` Eli Zaretskii
2005-09-16 18:03                         ` Stan Shebs
2005-09-16 20:50                           ` Eli Zaretskii
2005-09-23 23:20                             ` Stan Shebs
2005-09-16 17:50                       ` Ian Lance Taylor [this message]
2005-09-16 10:43                 ` Eli Zaretskii
2005-09-13 18:11 ` Min Xu (Hsu)
2005-09-13 22:01   ` Jim Blandy
2005-09-14  0:42     ` Stan Shebs
2005-09-16 12:03 ` Ramana Radhakrishnan
2005-09-20 22:47 Michael Snyder
2005-09-20 22:56 Michael Snyder
2005-09-20 23:14 ` Ian Lance Taylor
2005-09-21  3:40   ` Eli Zaretskii
2005-09-21  4:00     ` Ian Lance Taylor
2005-09-21 17:52       ` Eli Zaretskii
2005-09-21 20:37       ` Michael Snyder
2005-09-24  0:46         ` Stan Shebs
2005-09-24  1:10           ` Michael Snyder
2005-09-24 10:05           ` Eli Zaretskii
2005-09-27 22:00           ` Jim Blandy
2005-09-21  4:03     ` Daniel Jacobowitz
2005-09-21 16:56 ` Paul Gilliam
2005-09-23 23:44 ` Stan Shebs
2005-09-20 23:11 Michael Snyder
2005-09-24  0:07 ` Stan Shebs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3mzmcdhs0.fsf@gossamer.airs.com \
    --to=ian@airs.com \
    --cc=gdb@sourceware.org \
    --cc=shebs@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).