Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Hui Zhu <teawater@gmail.com>
Cc: gdb@sourceware.org, msnyder@vmware.com
Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like without 	prec)
Date: Fri, 30 Apr 2010 17:52:00 -0000	[thread overview]
Message-ID: <83iq78x1yz.fsf@gnu.org> (raw)
In-Reply-To: <t2sdaef60381004300623zd062f706k85a91e5cb6787934@mail.gmail.com>

> From: Hui Zhu <teawater@gmail.com>
> Date: Fri, 30 Apr 2010 21:23:20 +0800
> Cc: Michael Snyder <msnyder@vmware.com>
> 
> But lucky for us that insns exec rules we know.  So most of insns
> (There a some special, I will talk it later), if we have the a
> inferior value(memory and reg), we can get the each value of next
> insn.

I don't see how you can do that, unless you first read the entire
memory of the inferior.  Otherwise, when an instruction references
some address, how do you know what value is stored at that address?

Also, what do you do with features such as shared memory, where the
value at a given address can change beyond control of the current
inferior, and change the result of some instruction which references
that address?

> So if we can record the all the value of a inferior A(or all the value
> that will be change, but to get it will need parse the insns that will
> be exec, this is not easy.) , we can let the inferior exec without
> step.  If the user want reverse exec, get the each step value from A.
> Then the record speed will very faster than before.

But this preprocessing phase, won't it be prohibitively slow?

> 1.  How to record all the status of a inferior? For the linux,
> checkpoint already use fork to record the inferior.  So prec will use
> it too.
> And when we want get the old status of inferior step by step, we can
> let the forked process step by step.

If you need single-step the forked inferior, you will still need to
wait for the slow single-step execution, and the advantage of letting
the inferior run freely is lost, right?


  reply	other threads:[~2010-04-30 17:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-30 13:23 Hui Zhu
2010-04-30 17:52 ` Eli Zaretskii [this message]
2010-05-04  2:44   ` Hui Zhu
2010-05-04 17:51     ` Eli Zaretskii
2010-05-05  1:54       ` Hui Zhu
2010-05-05  2:49         ` Hui Zhu
     [not found] ` <362813.25386.qm@web112511.mail.gq1.yahoo.com>
2010-05-04  2:47   ` Hui Zhu
2010-05-05  4:04 ` paawan oza
2010-05-05  4:17   ` Hui Zhu
2010-05-19  7:19 ` Hui Zhu
2010-05-21  5:33   ` paawan oza
2010-05-21  5:42     ` Hui Zhu
2010-05-21  9:05       ` paawan oza
2010-05-21  7:42   ` Hui Zhu
2010-05-21  9:17     ` paawan oza

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=83iq78x1yz.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=msnyder@vmware.com \
    --cc=teawater@gmail.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