From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25267 invoked by alias); 3 May 2009 13:54:32 -0000 Received: (qmail 25257 invoked by uid 22791); 3 May 2009 13:54:31 -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; Sun, 03 May 2009 13:54:23 +0000 Received: by ti-out-0910.google.com with SMTP id a1so306679tib.12 for ; Sun, 03 May 2009 06:54:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.110.43.20 with SMTP id q20mr359651tiq.58.1241358859680; Sun, 03 May 2009 06:54:19 -0700 (PDT) In-Reply-To: <83ws91c5sp.fsf@gnu.org> References: <83ws91c5sp.fsf@gnu.org> Date: Sun, 03 May 2009 13:54: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/msg00051.txt.bz2 Hi Eli, 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. For example, arm will have a swi interface, mips will have a syscall interface. > > Also, some architectural overview of how the record/replay target > works would be nice, either in the comments or in gdbint.texinfo. =A0For > example, 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. Find out which register and memory will be changed in this insn. Record the old value of the reg and mem. So, syscall doesn't really need execute in function i386_linux_intx80_sysenter_record. > > It probably doesn't help that I don't know enough about how the target > stack works, but that isn't described, either, at least not in > target.[ch], right? =A0The only thing I found is some very high-level > description at the beginning of target.h. > I don't know which doc have the description for. Maybe read code target.c:update_current_target will help to make clear stack works. All of them are very good questions. Please tell me if you still have problems with them. Thanks, Hui