From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17075 invoked by alias); 7 Nov 2008 02:02:55 -0000 Received: (qmail 16945 invoked by uid 22791); 7 Nov 2008 02:02:53 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Nov 2008 02:02:17 +0000 Received: by ti-out-0910.google.com with SMTP id d10so485981tib.12 for ; Thu, 06 Nov 2008 18:02:13 -0800 (PST) Received: by 10.110.63.6 with SMTP id l6mr3047525tia.50.1226023333807; Thu, 06 Nov 2008 18:02:13 -0800 (PST) Received: by 10.110.42.9 with HTTP; Thu, 6 Nov 2008 18:02:13 -0800 (PST) Message-ID: Date: Fri, 07 Nov 2008 02:02:00 -0000 From: teawater To: "Doug Evans" Subject: Re: [RFA] Process record and replay, 8/10 Cc: "gdb-patches@sourceware.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: 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: 2008-11/txt/msg00113.txt.bz2 Thanks Doug, Others told me it too. But I don't know how to do it is better. Put "i386_process_record" to other file "i386-record". Or keep it in i386-tdep but let it call other function in other file "i386-record". The second is clear, but it's low quality. What do you guys think? On Fri, Nov 7, 2008 at 01:39, Doug Evans wrote: > On Wed, Nov 5, 2008 at 11:50 PM, teawater wrote: >> This patch add code to make I386 architecture support process record and replay. >> >> 2008-11-06 Hui Zhu >> >> I386 architecture process record and replay support. >> >> * i386-tdep.c (PREFIX_REPZ, PREFIX_REPNZ, PREFIX_LOCK, >> PREFIX_DATA, PREFIX_ADDR): New macros. Help decode the I386 >> instruction. >> (aflag, dflag, override, modrm, mod, reg, rm, ot, >> i386_record_pc): New variables. Ditto. >> (i386_record_modrm, i386_record_lea_modrm_addr, >> i386_record_lea_modrm): New functions. Ditto. >> (i386_process_record): New function. Parse the instruction in >> address "addr" and record the values of registers and memory >> that will be change in this instruction. >> (i386_gdbarch_init): Set "i386_process_record" to GDBARCH >> "process_record" interface. >> * i386-tdep.h (gdbarch_tdep): New function pointers >> "i386_intx80_record" and "i386_sysenter_record" that point to >> the function can record "intx80" and "sysenter" execute log. >> >> i386-tdep.c | 2706 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> i386-tdep.h | 3 >> 2 files changed, 2709 insertions(+) >> > > fwiw ... > > This is a case where I would REALLY like to see the code not live in > i386-tdep.c. > Maybe i386-tdep-.c? i386-.c? > Reverse execution is a significant enough and self-contained enough > feature that it (and gdb) would be more maintainable with more > isolation (so to speak). > [insert my usual wistfulness regarding building applications out of libraries] >