From: Jim Blandy <jimb@redhat.com>
To: "Min Xu (Hsu)" <xu@cs.wisc.edu>
Cc: Stan Shebs <shebs@apple.com>, gdb@sources.redhat.com
Subject: Re: Using reverse execution
Date: Tue, 13 Sep 2005 22:01:00 -0000 [thread overview]
Message-ID: <m3mzmgiq64.fsf@alligator.red-bean.com> (raw)
In-Reply-To: <20050913181057.GH5161@cs.wisc.edu> (Min Xu's message of "Tue, 13 Sep 2005 13:11:05 -0500")
ptrace allows you to stop the program just before and after it makes a
system call; this allows programs like strace to recover the
parameters that were passed, and the values returned. It's also
enough control to allow you to "replay" the system calls with values
you've saved earlier. Michael Chastain has written a program to do
this. The system call record would have to be related in the
appropriate way to whatever bookmarks or checkpoints the system
retained.
Some obvious restrictions:
- if you rewind and then modify the inferior's state, it may not make
the same system calls it did before. The illusion can't be
sustained, and you just have to punt somehow.
- Getting signals like SIGIO or SIGWINCH to arrive at exactly the same
points is something I just don't know how to do. It's clear how to
take and restore snapshots, but it's not clear how to recognize when
a system has re-reached a given state and should have its signal
re-delivered.
But it still seems like enough to be helpful in a lot of cases.
next prev parent reply other threads:[~2005-09-13 22:01 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
2005-09-16 10:43 ` Eli Zaretskii
2005-09-13 18:11 ` Min Xu (Hsu)
2005-09-13 22:01 ` Jim Blandy [this message]
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=m3mzmgiq64.fsf@alligator.red-bean.com \
--to=jimb@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=shebs@apple.com \
--cc=xu@cs.wisc.edu \
/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).