[Discussion/Prec] The record speed up plan (Make speed like without prec)
Hui Zhu
teawater@gmail.com
Wed May 5 04:17:00 GMT 2010
On Wed, May 5, 2010 at 12:04, paawan oza <paawan1982@yahoo.com> wrote:
> 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?
After "record".
>
> 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.
>
>
> > 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?
Yes, the first time reverse will be slow(Maybe sim exec will be more
fast). But I think it will be better than forward exec slow. And for
the reverse we can do more work to increase the speed.
Thanks,
Hui
>
>
>
>
> ----- 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
>
>
>
>
>
>
More information about the Gdb
mailing list