From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27337 invoked by alias); 21 May 2010 05:33:58 -0000 Received: (qmail 27324 invoked by uid 22791); 21 May 2010 05:33:56 -0000 X-SWARE-Spam-Status: No, hits=0.9 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 n6-vm0.bullet.mail.gq1.yahoo.com (HELO n6-vm0.bullet.mail.gq1.yahoo.com) (98.137.26.79) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 21 May 2010 05:33:52 +0000 Received: from [67.195.9.83] by n6.bullet.mail.gq1.yahoo.com with NNFMP; 21 May 2010 05:33:50 -0000 Received: from [98.137.27.208] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 21 May 2010 05:33:50 -0000 Received: from [127.0.0.1] by omp118.mail.gq1.yahoo.com with NNFMP; 21 May 2010 05:33:50 -0000 Received: (qmail 77492 invoked by uid 60001); 21 May 2010 05:33:50 -0000 Message-ID: <48573.77356.qm@web112518.mail.gq1.yahoo.com> Received: from [72.163.183.42] by web112518.mail.gq1.yahoo.com via HTTP; Thu, 20 May 2010 22:33:49 PDT References: Date: Fri, 21 May 2010 05:33: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/msg00062.txt.bz2 Hi Hui, would you please explain the idea of following lines ? if (lookup_minimal_symbol ("fork", NULL, NULL) !=3D NULL)=20 fork_fn =3D find_function_in_inferior ("fork", &fork_objf);=20 if (!fork_fn)=20 if (lookup_minimal_symbol ("_fork", NULL, NULL) !=3D NULL)=20 fork_fn =3D find_function_in_inferior ("fork", &fork_objf);=20 if (!fork_fn) + return -1; + ret =3D value_from_longest (builtin_= type (gdbarch)->builtin_int, 0);=20 /* Tell record.c that the following inferior change doesn't need record. *= /=20 old_cleanups =3D record_disable_set (); + +=20=20 /* Tell target that this is linux pre-record. */=20 self_cleanups =3D make_cleanup_restore_integer (&linux_pre_recor= ding); + linux_pre_recording =3D 1;=20 ret =3D call_function_by_hand (fork_fn, 0, &ret); + + do_cleanups (s= elf_cleanups); PS: I am unable to find some definations e.g. find_function_in_inferior please comment. Regards, Oza. ----- Original Message ---- From: Hui Zhu To: gdb@sourceware.org Cc: Michael Snyder ; paawan oza ;= Eli Zaretskii Sent: Wed, May 19, 2010 12:48:50 PM Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like w= ithout prec) Hi, This is a demo. Still not support segment register, system call and some others. 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. Th= anks. > > Thanks, > Hui >