From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20525 invoked by alias); 15 Oct 2008 18:52:56 -0000 Received: (qmail 20515 invoked by uid 22791); 15 Oct 2008 18:52:56 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Oct 2008 18:52:21 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 09C2328007; Wed, 15 Oct 2008 11:52:19 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost5.vmware.com (Postfix) with ESMTP id F25B5DC061; Wed, 15 Oct 2008 11:52:18 -0700 (PDT) Message-ID: <48F63B15.3070705@vmware.com> Date: Wed, 15 Oct 2008 18:52:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii CC: teawater , "gdb-patches@sourceware.org" Subject: Re: [reverse RFC] Add documentation for process record and replay References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-10/txt/msg00381.txt.bz2 Eli Zaretskii wrote: >> Date: Wed, 15 Oct 2008 13:50:30 +0800 >> From: teawater >> Cc: gdb-patches@sourceware.org, msnyder@vmware.com >> >>>> +When this target is in use, if the next instruction to be executed is in the >>>> +execution log, @value{GDBN} will debug in replay mode so that all the >>>> +execution events are taken from the execution log. Otherwise, @value{GDBN} >>>> +will debug in record mode and record the execution log while executing >>>> +normally. >>> What exactly is the "execution log"? You talk about "next >>> instruction", which seems to hint that the log records the machine >>> instructions executed by the inferior -- is that true? If so, what >>> are the "execution events" you mention here -- are they just a synonym >>> for the "instructions", or are they something else? >>> >> "execution log" mean is before a instruction execute, record the >> values of register and memory that will be change in this instruction >> to a list. > > So you record the values of registers and memory AND the instruction? > The frequent use of ``instruction'' and ``insn'' is a clear hint to > this; if as a matter of fact the instructions are not recorded, we > should modify the text to eliminate those hints. Eli, I think the relation is that we will save one log entry for each instruction executed. Not necessarily that we save the instruction itself, but since we do save the PC (it being part of the state that is changed by executing the instruction), we always have access to the instruction itself if we want it (either in memory or in object file).