From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11484 invoked by alias); 15 Oct 2008 05:51:09 -0000 Received: (qmail 11471 invoked by uid 22791); 15 Oct 2008 05:51:08 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.190) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Oct 2008 05:50:33 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1636129tib.12 for ; Tue, 14 Oct 2008 22:50:30 -0700 (PDT) Received: by 10.110.10.11 with SMTP id 11mr400409tij.5.1224049830401; Tue, 14 Oct 2008 22:50:30 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Tue, 14 Oct 2008 22:50:30 -0700 (PDT) Message-ID: Date: Wed, 15 Oct 2008 05:51:00 -0000 From: teawater To: "Eli Zaretskii" Subject: Re: [reverse RFC] Add documentation for process record and replay Cc: gdb-patches@sourceware.org, msnyder@vmware.com 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-10/txt/msg00360.txt.bz2 Hi Eli, On Wed, Oct 15, 2008 at 00:33, Eli Zaretskii wrote: >> Date: Tue, 14 Oct 2008 23:00:59 +0800 >> From: teawater >> >> This patch add doc to gdb.texinfo. >> >> 2008-10-14 Hui Zhu >> >> * gdb.texinfo: Add documentation for process record and replay. > > Thank you. I have a few questions and suggestions about this. > Thanks for your questions and suggestions. All of them are very good. >> +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. This list is called "execution log". In replay mode, inferior will not execute actually. It will just execute in GDB itself. So this called "execution events". I am trying to talk clear this in a internal doc that I am writing. >> +Process record and replay target can only debug a process that already >> +running. Therefore you need to first start the process @code{run}, >> +and then start the recording @code{record}. > > This is really inconvenient, because it means the beginning of the > program's execution cannot be recorded. Is that a limitation, or am I > missing something? Cause P record will record the values before instruction execute. So it can't work before program's begin. And I don't think we need it. Cause most of time, people just care about program execute after "main". You can set a breakpoint in "main" and open P record when inferior break in there. Or if you care about a lot of thing before "main". You can set a breakpoint in "_start" and open P record when inferior break in there. > > This: > >> +@item stoprecord >> +Stop process record and replay target at once. When Process record and >> +replay target stops, all the execution log will be deleted and the inferior >> +will either be terminated, or remain in its final state. > > and this: > >> +When you stop the process record and replay target in record mode (at the >> +end of the execution log), the inferior will be stopped at the next >> +instruction that would have been recorded. > > seem to be in contradiction: the former says that the inferior will be > terminated, the latter says that it will be stopped. Which one is it? "terminated" is a suggest from Michael. I think it's mean is stop in there. > >> In other words, if you record >> +for a while and then stop recording, the inferior process will be left in >> +the same state as if you had never done any recording. > > Why is this sentence important? Recording has no side effects except > for the recorded information, so why did you need to say that the > inferior will be left in a state ``as if recording never happened''? > OK. I will change it. >> +@itemx set record-auto-delete 1 >> +Set the behavior when record instructions limit is reached. 1 mean that GDB >> +will auto delete the oldest record to make room for each new one. >> + >> +@item set record-auto-delete 0 >> +0 is the default value, meaning that @value{GDBN} will stop the inferior. > > Either the name of the option or the argument should be modified, > IMO. I prefer to rename the option (to something like > record-stop-at-limit, and change the default to 1). > > Also, there's a relation between this option and > record-insn-number-max, right? If so, the text should mention that. > I think 0 is better than 1. Cause when GDB stop, it will ask user how to do stop or set record-auto-delete to 1. I think it's user experience is better than default to 1. Maybe I need add more introduce to record-auto-delete 0. "record-stop-at-limit" is better. I will change it. :) >> +@item set record-insn-number-max @var{limit} >> +Set the limit of instructions to be recorded. Default value is 200000. >> +If set to 0, record instructions number limit function will disable. >> +In this case, if record instructions number is bigger than @var{limit}, >> +@value{GDBN} will auto delete the earliest recorded instruction to make room >> +for each new one. > > I think you need to transpose the two last sentences, otherwise the > text seems to say that when the limit is set to zero, GDB will delete > earliest instruction when the (zero) limit is exhausted. > I will transpose the two last sentences. If the limit is set to zero, it will delete nothing. I will add some introduce to this part. Thanks, Hui