From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 533 invoked by alias); 21 May 2010 09:17:16 -0000 Received: (qmail 524 invoked by uid 22791); 21 May 2010 09:17:15 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from n5-vm1.bullet.mail.gq1.yahoo.com (HELO n5-vm1.bullet.mail.gq1.yahoo.com) (67.195.8.63) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 21 May 2010 09:17:09 +0000 Received: from [67.195.9.83] by n5.bullet.mail.gq1.yahoo.com with NNFMP; 21 May 2010 09:17:08 -0000 Received: from [98.137.27.210] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 21 May 2010 09:17:08 -0000 Received: from [127.0.0.1] by omp120.mail.gq1.yahoo.com with NNFMP; 21 May 2010 09:17:08 -0000 Received: (qmail 35874 invoked by uid 60001); 21 May 2010 09:17:08 -0000 Message-ID: <959869.35558.qm@web112508.mail.gq1.yahoo.com> Received: from [72.163.183.42] by web112508.mail.gq1.yahoo.com via HTTP; Fri, 21 May 2010 02:17:07 PDT References: Date: Fri, 21 May 2010 09:17:00 -0000 From: paawan oza Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like without prec) To: Hui Zhu , gdb@sourceware.org Cc: Michael Snyder , Eli Zaretskii In-Reply-To: MIME-Version: 1.0 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/msg00066.txt.bz2 Hi Hui, I have some doubts, which I would like to get clarified. 1) In this approach, we fork and create child the moment user does 'record'= right ? 2) Now we parent/chile and let other freely run, right ? 3) when user wants to do reverse we record parent/child insns right ? 4) how are we planning to handle events like (sending signals, closing file= s, freeing memory etc...), and some special instructions which changes some= hw configuration may be... will not all these happen twice ? Regards, Oza. ----- Original Message ---- From: Hui Zhu To: gdb@sourceware.org Cc: Michael Snyder ; paawan oza ;= Eli Zaretskii Sent: Fri, May 21, 2010 1:12:22 PM Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like w= ithout prec) On Wed, May 19, 2010 at 15:18, Hui Zhu wrote: > Hi, > > This is a demo. > > Still not support segment register, system call and some others. > > Thanks, > Hui > Before I send RFA for these patches, I think there are 12 parts need comple= te: 1. Find a better name. Maybe it can be change to checkpoint record or something. 2. The code that check the record_ptid and inferior_ptid is exec to the same place need to more works. Now, it check the stop_pc, all the registers and the frame. But if the code like: for (i =3D 1; i< 99; i++) go(); If the inferior stop in the go() and replay. The stop_pc , reg and frame will be same. So I think we need add the check for memory change. The inferior exec to the same place, the memory that changed must be same. So Check the each record_mem addr of record_ptid and inferior_ptid. If all of them are same. I think it is really same. 3. System call support. Like what I said in the plan. We need support system call with catch point. 4. handle special insns that we will not know what will happen after it exe= c. Like what I said in the plan. Give them up. 5. Signal support. Need do special record (maybe fork), when record_ptid inferior exec to this point, record this signal. 6. User change the memory when record. It need special record like signal. 7. In demo, record.c call ptrace to kill the record_ptid and call linux_nat_switch_fork to switch ptid. I think both of them need a target interface. 8. When gdb get record_list from record_ptid. Ctrl-c can stop it. 9. Let user can use goto command to the begin and end of record_list without get each record_list from record_ptid. It will make reverse debug more speed up. 10. record_end have a insn_num to help goto. I am not sure we can support it now. Maybe we can close it when record pre is opened. 11. record_insn_max, I need make it works OK with pre prec or close it when record pre is opened. 12. Make record save works OK with record pre. Thanks, Hui > On Fri, Apr 30, 2010 at 21:23, Hui Zhu wrote: >> 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=EF=BC=9F 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. T= hanks. >> >> Thanks, >> Hui >> >