From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35010 invoked by alias); 11 Apr 2019 15:55:26 -0000 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 Received: (qmail 34239 invoked by uid 89); 11 Apr 2019 15:54:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=ring, Replay, replay, activated X-HELO: mail-wr1-f53.google.com Received: from mail-wr1-f53.google.com (HELO mail-wr1-f53.google.com) (209.85.221.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Apr 2019 15:54:25 +0000 Received: by mail-wr1-f53.google.com with SMTP id t17so7991392wrw.13 for ; Thu, 11 Apr 2019 08:54:25 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id v17sm4621261wmc.30.2019.04.11.08.54.22 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 08:54:22 -0700 (PDT) Subject: Re: reverse execution part of the manual is written backwards To: Eli Zaretskii , Pedro Alves Cc: eggert@cs.ucla.edu, gdb-patches@sourceware.org References: <5fbd40b5-7887-1000-3457-75190a5d96c0@cs.ucla.edu> <51cb91ba-6bcd-3de9-43d4-c766e2737c88@redhat.com> <831s297vwi.fsf@gnu.org> From: Pedro Alves Message-ID: <111cf816-c27c-fe5d-7cb8-31375ad1cbc2@redhat.com> Date: Thu, 11 Apr 2019 15:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <831s297vwi.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-04/txt/msg00203.txt.bz2 On 4/10/19 3:54 PM, Eli Zaretskii wrote: >> From: Pedro Alves >> Date: Wed, 10 Apr 2019 12:51:36 +0100 >> >>> +Before using reverse execution, you should first use the @code{record} >>> +command, so that instructions executed by the program are saved for >>> +reverse execution later.  @xref{Process Record and Replay}. >>> +@value{GDBN} provides the following commands to examine the process >>> +record and execute the program in reverse. >> >> This is not correct. "record" is one way to support reverse execution, >> but there are others. For example, "record" is an alias for "record full". >> "record btrace" also supports reverse debugging. And then there are >> remote targets that suppose reverse debugging natively, like system emulators, >> and you won't type "record" with those at all. Mozilla's RR is another >> example. >> >> https://www.gnu.org/software/gdb/news/reversible.html > > Pedro, > > First, thanks for responding, I posted a similar question to gdb@, and > only got one uncertain response. What you wrote is much more > definitive. Sorry, wish I could answer every question. > Next, please try to put yourself in the shoes of a GDB user who is > debugging a native target, let's say on GNU/Linux. How would such a > user know what to do to start using the reverse debugging feature? > > The above URL basically says that reverse debugging is available > natively only on GNU/Linux running on x86 CPUs, and then only if one > activates "target record". This is essentially what Paul was saying, > so he wasn't very far off the mark. The remote targets are an > important addition to what Paul said. > > In any case, I think the Reverse Execution section should say > something about the conditions for using this mode, regardless of > whether it precedes or follows the chapter about recording and > replaying. It probably should simply say what the above URL says at > its beginning, and then describe the commands to activate the correct > target, or point to a clear description of those commands elsewhere in > the manual. Because right now we have a description of record and > replay, and we have a description of reverse-execution commands, but > no "glue" to connect them, and there's no reasonable way for a reader > to guess what to do to bridge over that chasm. > > Do you agree? > How about this? >From ed99ed89bf0d06edf844eaa018619d617b9bb99b Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Thu, 11 Apr 2019 16:03:33 +0100 Subject: [PATCH] Improve reverse debugging docs * gdb.texinfo (Reverse Execution): Mention and xref process record and replay. Mention remote and system emulators. (Process Record and Replay): List supported architectures. Mention that "record btrace" is only supported on Intel processors. --- gdb/doc/gdb.texinfo | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index f410d026b82..aa5b8756b7c 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -6697,6 +6697,12 @@ assumes that the memory and registers that the target reports are in a consistant state, but @value{GDBN} accepts whatever it is given. }. +On some platforms, @value{GDBN} has built-in support for reverse +execution, activated with the @code{record} or @code{record btrace} +commands. @xref{Process Record and Replay}. Some remote targets, +typically full system emulators, support reverse execution directly +without requiring any special command. + If you are debugging in a target environment that supports reverse execution, @value{GDBN} provides the following commands. @@ -6817,6 +6823,11 @@ replay mode as long as the execution log includes the record for the previous instruction; otherwise, it will work in record mode, if the platform supports reverse execution, or stop if not. +Currently, process record and replay is supported on ARM, Aarch64, +Moxie, PowerPC, PowerPC64, S/390, and x86 (i386/amd64) running +GNU/Linux. Process record and replay can be used both when native +debugging, and when remote debugging via @code{gdbserver}. + For architecture environments that support process record and replay, @value{GDBN} provides the following commands: @@ -6851,13 +6862,14 @@ replay implementation. This method allows replaying and reverse execution. @item btrace @var{format} -Hardware-supported instruction recording. This method does not record -data. Further, the data is collected in a ring buffer so old data will -be overwritten when the buffer is full. It allows limited reverse -execution. Variables and registers are not available during reverse -execution. In remote debugging, recording continues on disconnect. -Recorded data can be inspected after reconnecting. The recording may -be stopped using @code{record stop}. +Hardware-supported instruction recording, supported on Intel +processors. This method does not record data. Further, the data is +collected in a ring buffer so old data will be overwritten when the +buffer is full. It allows limited reverse execution. Variables and +registers are not available during reverse execution. In remote +debugging, recording continues on disconnect. Recorded data can be +inspected after reconnecting. The recording may be stopped using +@code{record stop}. The recording format can be specified as parameter. Without a parameter the command chooses the recording format. The following recording -- 2.14.5