From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11612 invoked by alias); 4 May 2009 11:15:05 -0000 Received: (qmail 11560 invoked by uid 22791); 4 May 2009 11:15:03 -0000 X-SWARE-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_00,BOTNET,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout1.012.net.il (HELO mtaout1.012.net.il) (84.95.2.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 May 2009 11:14:57 +0000 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KJ400G009R04U00@i-mtaout1.012.net.il> for gdb-patches@sourceware.org; Mon, 04 May 2009 14:14:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.230.216]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KJ4009S49VFV020@i-mtaout1.012.net.il>; Mon, 04 May 2009 14:14:04 +0300 (IDT) Date: Mon, 04 May 2009 11:15:00 -0000 From: Eli Zaretskii Subject: Re: Process record and replay checked in to main trunk In-reply-to: To: Hui Zhu Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83prepdss5.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <83ws91c5sp.fsf@gnu.org> 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/msg00056.txt.bz2 > 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.  Apologies 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?  (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. For > 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. Is 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? > > 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.  The syscall itself does not happen inside > > record_linux_system_call, that just records the syscall parameters and > > data buffers, right?  And recording happens _before_ the instruction > > being recorded executes, right?  So 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?  What am I missing > > here? > > This is because all record work will be done before insn execute. > Before insn execute, p record parse this insn. Find out which > register and memory will be changed in this insn. Record 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?