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

[Hui Zhu <teawater at gmail dot com>]

On Sat, May 1, 2010 at 11:12, paawan oza <paawan1982@yahoo.com> wrote:
> Hi,
>
> please find my analysis below.
>
>>> the first thing is, how can we rely on recording volatile memory locations. infact is is even problem with curent prec, as the moment w are going to record next insn and volatile locations are changed then ?
>
>>> another point as Eli suggested, share memory, shared semaphores in short memory which we do not have control over at a particular time.
>
>>> we dont know how big is the process, and we try to record everything from the beginning, and we use memory (are we going to come up with file concept for prec info !! ), then we exhaust virtuall address space may be, and use may not need that much of prec also.
>
>>> Âcurrently we have not talkd to kernel guys to provide kernel support for reversible debigging, which should essentially support reversible debugging of signals, I/O and many more primitive things, I am not sure how this model will fit over there because there may be many asynchronous events we might want to play it reverse.

I still didn't find some thing need kernel do.
I need inferior stop on special insn like rdtsc, but looks x86 cpu
doesn't support it.

Thanks,
Hui

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