From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9328 invoked by alias); 14 Oct 2008 16:34:31 -0000 Received: (qmail 9317 invoked by uid 22791); 14 Oct 2008 16:34:30 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout3.012.net.il (HELO mtaout3.012.net.il) (84.95.2.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Oct 2008 16:33:50 +0000 Received: from HOME-C4E4A596F7 ([77.127.24.3]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K8Q00N4RM2K0X30@i_mtaout3.012.net.il> for gdb-patches@sourceware.org; Tue, 14 Oct 2008 18:35:08 +0200 (IST) Date: Tue, 14 Oct 2008 16:34:00 -0000 From: Eli Zaretskii Subject: Re: [reverse RFC] Add documentation for process record and replay In-reply-to: X-012-Sender: halo1@inter.net.il To: teawater Cc: gdb-patches@sourceware.org, msnyder@vmware.com Reply-to: Eli Zaretskii Message-id: 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/msg00350.txt.bz2 > 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. > +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? > +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? 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? > 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''? > +@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. > +@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.