From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23863 invoked by alias); 21 May 2010 09:05:26 -0000 Received: (qmail 23849 invoked by uid 22791); 21 May 2010 09:05:23 -0000 X-SWARE-Spam-Status: No, hits=0.2 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 n2-vm1.bullet.mail.gq1.yahoo.com (HELO n2-vm1.bullet.mail.gq1.yahoo.com) (67.195.23.155) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 21 May 2010 09:05:15 +0000 Received: from [67.195.9.81] by n2.bullet.mail.gq1.yahoo.com with NNFMP; 21 May 2010 09:05:13 -0000 Received: from [98.137.27.208] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 21 May 2010 09:05:13 -0000 Received: from [127.0.0.1] by omp118.mail.gq1.yahoo.com with NNFMP; 21 May 2010 09:05:13 -0000 Received: (qmail 62490 invoked by uid 60001); 21 May 2010 09:05:13 -0000 Message-ID: <765972.60635.qm@web112512.mail.gq1.yahoo.com> Received: from [72.163.183.42] by web112512.mail.gq1.yahoo.com via HTTP; Fri, 21 May 2010 02:05:13 PDT References: <48573.77356.qm@web112518.mail.gq1.yahoo.com> Date: Fri, 21 May 2010 09:05:00 -0000 From: paawan oza Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like without prec) To: Hui Zhu Cc: gdb@sourceware.org, 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/msg00065.txt.bz2 no, I did not patch. I just tried to study the lines in your patch, which seem to be core lines. ----- Original Message ---- From: Hui Zhu To: paawan oza Cc: gdb@sourceware.org; Michael Snyder ; Eli Zaretskii = Sent: Fri, May 21, 2010 11:12:00 AM Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like w= ithout prec) Are you use gdb-cvs-head? Hui On Fri, May 21, 2010 at 13:33, paawan oza wrote: > Hi Hui, > > would you please explain the idea of following lines ? > > if (lookup_minimal_symbol ("fork", NULL, NULL) !=3D NULL) > fork_fn =3D find_function_in_inferior ("fork", &fork_objf); > if (!fork_fn) > if (lookup_minimal_symbol ("_fork", NULL, NULL) !=3D NULL) > fork_fn =3D find_function_in_inferior ("fork", &fork_objf); > if (!fork_fn) + return -1; + ret =3D value_from_longest (builtin= _type (gdbarch)->builtin_int, 0); > /* Tell record.c that the following inferior change doesn't need record.= */ > old_cleanups =3D record_disable_set (); + + > /* Tell target that this is linux pre-record. */ > self_cleanups =3D make_cleanup_restore_integer (&linux_pre_reco= rding); + linux_pre_recording =3D 1; > ret =3D call_function_by_hand (fork_fn, 0, &ret); + + do_cleanups (= self_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 = without 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. T= hanks. >> >> Thanks, >> Hui >> > > > > >