This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Discussion/Prec] The record speed up plan (Make speed like without prec)


On Sat, May 1, 2010 at 01:52, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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?
>

You mean before or after the insn?

For the before, we do something like fork to record all of them.
For the after, as my insns knowledge most of them can be got follow
the rules.  A lot of simualtor do something like it.

> 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?

Agree, but we can give up of them like we give up the released memory now.

>
> > 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?

I am not sure the preprocessing phase is slow or not.  I think the
more big trouble is handle branch will be very hard.
So I give it up.

Do fork directly will be more speed up.

>
> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]