Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: paawan oza <paawan1982@yahoo.com>
To: Hui Zhu <teawater@gmail.com>, gdb@sourceware.org
Cc: Michael Snyder <msnyder@vmware.com>
Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like without  prec)
Date: Wed, 05 May 2010 04:04:00 -0000	[thread overview]
Message-ID: <557165.23885.qm@web112507.mail.gq1.yahoo.com> (raw)
In-Reply-To: <t2sdaef60381004300623zd062f706k85a91e5cb6787934@mail.gmail.com>

Hi,

I have some understanding about followingwhat you wrote in previous mail.

"But this way have a 2 question.
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.  That will easy by parse the insn
and know what will happen."

I have some queries.

1) when the process is attached to gdb, and user starts debugging, at what moment we do fork? 

2) so you mean to say, forked process will freely run, and still we continue to record parent step by step ?
in above case if we want to play reverse, we still need to depend on the speed of recording/steeping of parent.

Regards,
Oza.




----- Original Message ----
From: Hui Zhu <teawater@gmail.com>
To: gdb@sourceware.org
Cc: Michael Snyder <msnyder@vmware.com>
Sent: Fri, April 30, 2010 6:53:20 PM
Subject: [Discussion/Prec] The record speed up plan (Make speed like without  prec)

Hello,

I think the record speed is the biggest trouble of prec.
After I did a long think and a lot of test around with it.  I got a
idea.  Actually, I have began the code work.

I found that the big trouble is prec let the inferior just step.  It
make inferior speed very low.  Because the setp need a lot of context
works.
So I think let inferior continue can make it speed up.  But How to
record the change of each step?

Some physicists said all the things in the world have execution rules.
So use the current stat of this thing, we will get what will happen
in the future.  Looks most of rules are still not found.  :)

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.
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 way have a 2 question.
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.  That will easy by parse the insn
and know what will happen.

2.  How to handle special insns that we will not know what will happen
after it exec?
The first type of this insns is system call.  Linux have catchpoint
that make inferior stop before and after syscall.  Then we can record
the change after the system call.
The other insn is like rdtsc, I don't know howto get the feature value
of this type.  My current idea with them is give up all the record
after this insn.
If user need, insert special breakpoint for it.  Next time, inferior
will stop on this insn, then prec can record the value after it exec.

BTW, I call this new function pre_record, I agree with you if you said
this name is ugly. :)

Please tell me your opinions about my idea.  That will help me a lot.  Thanks.

Thanks,
Hui






  parent reply	other threads:[~2010-05-05  4:04 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
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 [this message]
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=557165.23885.qm@web112507.mail.gq1.yahoo.com \
    --to=paawan1982@yahoo.com \
    --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