From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12029 invoked by alias); 30 Apr 2010 13:23:55 -0000 Received: (qmail 11934 invoked by uid 22791); 30 Apr 2010 13:23:49 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,SARE_MSGID_LONG45,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-pv0-f169.google.com (HELO mail-pv0-f169.google.com) (74.125.83.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Apr 2010 13:23:42 +0000 Received: by pva4 with SMTP id 4so116998pva.0 for ; Fri, 30 Apr 2010 06:23:40 -0700 (PDT) Received: by 10.142.250.21 with SMTP id x21mr6719048wfh.263.1272633820221; Fri, 30 Apr 2010 06:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.4.9 with HTTP; Fri, 30 Apr 2010 06:23:20 -0700 (PDT) From: Hui Zhu Date: Fri, 30 Apr 2010 13:23:00 -0000 Message-ID: Subject: [Discussion/Prec] The record speed up plan (Make speed like without prec) To: gdb@sourceware.org Cc: 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-04/txt/msg00161.txt.bz2 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. Than= ks. Thanks, Hui