From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20852 invoked by alias); 5 May 2009 13:40:00 -0000 Received: (qmail 20839 invoked by uid 22791); 5 May 2009 13:39:59 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.185) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 May 2009 13:39:53 +0000 Received: by ti-out-0910.google.com with SMTP id a1so447962tib.12 for ; Tue, 05 May 2009 06:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.110.105.5 with SMTP id d5mr6336tic.6.1241530790535; Tue, 05 May 2009 06:39:50 -0700 (PDT) In-Reply-To: <83prepdss5.fsf@gnu.org> References: <83ws91c5sp.fsf@gnu.org> <83prepdss5.fsf@gnu.org> Date: Tue, 05 May 2009 13:40:00 -0000 Message-ID: Subject: Re: Process record and replay checked in to main trunk From: Hui Zhu To: Eli Zaretskii Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00084.txt.bz2 On Mon, May 4, 2009 at 19:14, Eli Zaretskii wrote: >> Date: Sun, 3 May 2009 21:54:19 +0800 >> From: Hui Zhu >> Cc: gdb-patches@sourceware.org >> >> On Fri, May 1, 2009 at 21:27, Eli Zaretskii wrote: >> > It would be nice if i386-tdep.c had some comments about what it takes >> > for another x86 target to add support for process recording and >> > replay. =A0Apologies if it's already described somewhere and I missed >> > it. >> > >> > It looks like all is needed is to define suitable functions for >> > tdep->i386_intx80_record and tdep->i386_sysenter_record, is that >> > right? =A0(If so, why so Linux-centric names?) >> >> The intx80 and sysenter function pointers is the interface for >> i386-os-tdep code to set intx86 insn and sysenter special record >> functions. >> Because some os (linux) have special function in intx80 and sysenter >> (system call). >> >> So, in other arch, maybe there will have other interface. =A0For >> example, arm will have a swi interface, mips will have a syscall >> interface. > > Right, but I was asking about another _x86_ target, not just any > target. =A0Is there anything an i386 target needs to do to get process > record and replay work, except define suitable i386_intx80_record and > i386_sysenter_record functions? Yes, if they use sysenter or intx80 to be syscall. They need set these function pointers with themselves. If some os use another insn to be syscall. the prec in i386-tdep need update to support interface for it. > >> > just looking at i386_linux_intx80_sysenter_record, I cannot >> > understand how it succeed to record both the arguments to the syscall >> > and the return value. =A0The syscall itself does not happen inside >> > record_linux_system_call, that just records the syscall parameters and >> > data buffers, right? =A0And recording happens _before_ the instruction >> > being recorded executes, right? =A0So how come >> > i386_linux_intx80_sysenter_record can use EAX as the syscall number >> > and immediately after the call to record_linux_system_call treat the >> > value of EAX as the value returned by the syscall? =A0What am I missing >> > here? >> >> This is because all record work will be done before insn execute. >> Before insn execute, p record parse this insn. =A0Find out which >> register and memory will be changed in this insn. =A0Record the old >> value of the reg and mem. > > Okay, and when will they record the new values of the registers and > memory affected by the syscall? > Prec will not record the new value in forward execute because this value is in inferior. When reverse execute, prec wll record the new value and set old value to inferior. Thanks, Hui