From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22130 invoked by alias); 1 May 2009 13:28:57 -0000 Received: (qmail 22112 invoked by uid 22791); 1 May 2009 13:28:56 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 May 2009 13:28:50 +0000 Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KIY00M00VVNEO00@i-mtaout7.012.net.il> for gdb-patches@sourceware.org; Fri, 01 May 2009 16:26:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.230.216]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KIY00MB4W0RK560@i-mtaout7.012.net.il>; Fri, 01 May 2009 16:26:52 +0300 (IDT) Date: Fri, 01 May 2009 13:28: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: <83ws91c5sp.fsf@gnu.org> 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: 2009-05/txt/msg00016.txt.bz2 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?) Also, some architectural overview of how the record/replay target works would be nice, either in the comments or in gdbint.texinfo. For 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. 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? 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? The only thing I found is some very high-level description at the beginning of target.h.