From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32696 invoked by alias); 4 May 2010 02:47:05 -0000 Received: (qmail 32684 invoked by uid 22791); 4 May 2010 02:47:03 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45 X-Spam-Check-By: sourceware.org Received: from mail-pw0-f41.google.com (HELO mail-pw0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 May 2010 02:46:56 +0000 Received: by pwi10 with SMTP id 10so1737766pwi.0 for ; Mon, 03 May 2010 19:46:55 -0700 (PDT) Received: by 10.142.1.22 with SMTP id 22mr82611wfa.345.1272941215260; Mon, 03 May 2010 19:46:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.4.9 with HTTP; Mon, 3 May 2010 19:46:35 -0700 (PDT) In-Reply-To: <362813.25386.qm@web112511.mail.gq1.yahoo.com> References: <362813.25386.qm@web112511.mail.gq1.yahoo.com> From: Hui Zhu Date: Tue, 04 May 2010 02:47:00 -0000 Message-ID: Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like without prec) To: paawan oza Cc: gdb@sourceware.org, Michael Snyder Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00005.txt.bz2 On Sat, May 1, 2010 at 11:12, paawan oza wrote: > Hi, > > please find my analysis below. > >>> the first thing is, how can we rely on recording volatile memory locati= ons. 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 shor= t 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 fr= om the beginning, and we use memory (are we going to come up with file conc= ept for prec info !! ), then we exhaust virtuall address space may be, and = use may not need that much of prec also. > >>> =C2=A0currently we have not talkd to kernel guys to provide kernel supp= ort for reversible debigging, which should essentially support reversible d= ebugging 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 event= s 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 > To: gdb@sourceware.org > Cc: Michael Snyder > Sent: Fri, April 30, 2010 6:53:20 PM > Subject: [Discussion/Prec] The record speed up plan (Make speed like with= out =C2=A0prec) > > 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. =C2=A0I got a > idea. =C2=A0Actually, I have began the code work. > > I found that the big trouble is prec let the inferior just step. =C2=A0It > make inferior speed very low. =C2=A0Because the setp need a lot of context > works. > So I think let inferior continue can make it speed up. =C2=A0But 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. =C2=A0Looks most of rules are still not found. =C2=A0:) > > But lucky for us that insns exec rules we know. =C2=A0So 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. =C2=A0If 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. =C2=A0How to record all the status of a inferior=EF=BC=9F For the linu= x, > checkpoint already use fork to record the inferior. =C2=A0So 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. =C2=A0That will easy by parse the in= sn > and know what will happen. > > 2. =C2=A0How to handle special insns that we will not know what will happ= en > after it exec? > The first type of this insns is system call. =C2=A0Linux have catchpoint > that make inferior stop before and after syscall. =C2=A0Then 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. =C2=A0My current idea with them is give up all the record > after this insn. > If user need, insert special breakpoint for it. =C2=A0Next 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. =C2=A0That will help me a lot= . =C2=A0Thanks. > > Thanks, > Hui > > > > > >