From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22158 invoked by alias); 17 Oct 2008 15:16:53 -0000 Received: (qmail 22149 invoked by uid 22791); 17 Oct 2008 15:16:53 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.186) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Oct 2008 15:16:18 +0000 Received: by ti-out-0910.google.com with SMTP id d10so352667tib.12 for ; Fri, 17 Oct 2008 08:16:12 -0700 (PDT) Received: by 10.110.90.9 with SMTP id n9mr3158993tib.22.1224256572496; Fri, 17 Oct 2008 08:16:12 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Fri, 17 Oct 2008 08:16:12 -0700 (PDT) Message-ID: Date: Fri, 17 Oct 2008 15:16:00 -0000 From: teawater To: "Eli Zaretskii" Subject: Re: [reverse RFC] Add documentation for process record and replay Cc: msnyder@vmware.com, 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: <48F63B15.3070705@vmware.com> 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/msg00433.txt.bz2 On Fri, Oct 17, 2008 at 18:06, Eli Zaretskii wrote: >> Date: Fri, 17 Oct 2008 11:17:59 +0800 >> From: teawater >> Cc: msnyder@vmware.com, gdb-patches@sourceware.org >> >> Thanks Eli. >> I make a new one. > > Almost there ;-) > >> > I'm somewhat concerned about the fact that the functionality and >> > limitations of the ``record and replay'' target are not described at >> > all. If I were to debug using such an architecture, I'd like to know >> > what it can and cannot do. For example, if I replay, does the I/O >> > happen like it happened during the recorded session? What about >> > signals? crashes? etc. Are there things that simply cannot be >> > reproduced exactly, due to fundamental limitations of the replay >> > target? > > Do you have an opinion about these concerns? I had added some introduce after "@cindex recording programs running message and replay it". When this target is in use, if the execution log includes the record for the next instruction, @value{GDBN} will debug in replay mode. So inferior will not really execute and all the execution events are taken from the execution log. Just the values of registers (include pc register) and memory of the inferior will be changed. > >> +Stop process record and replay target at once. When Process record and > ^^ > Still one space. > >> +earlier point), the inferior process will become ``live" at that earlier state, > > ``live'', not ``live". (There are more cases of this in the text.) > Thanks, I will fix them.