reverse execution part of the manual is written backwards

Message ID 5fbd40b5-7887-1000-3457-75190a5d96c0@cs.ucla.edu
State New, archived
Headers

Commit Message

Paul Eggert April 10, 2019, 4:19 a.m. UTC
  [resent from https://sourceware.org/bugzilla/show_bug.cgi?id=24417]

At least two Emacs developers were confused by GDB's documentation for reverse 
execution. One said he could never get it to work and recommended another 
debugger instead since it always worked for him. We tracked down the issue to a 
problem in GDB's documentation: it documents how to do reverse execution, but 
never mentions until a later section that you can't use reverse execution unless 
you first turn on process recording.

Surely it's not intended that one must read the GDB documentation backwards in 
order to know how to do reverse execution....

Proposed patch follows. This is just a minor doc patch so I assume no ChangeLog 
entry is needed.

  @kindex reverse-continue
  

Comments

Pedro Alves April 10, 2019, 11:51 a.m. UTC | #1
On 4/10/19 5:19 AM, Paul Eggert wrote:
> [resent from https://sourceware.org/bugzilla/show_bug.cgi?id=24417]
> 
> At least two Emacs developers were confused by GDB's documentation for reverse execution. One said he could never get it to work and recommended another debugger instead since it always worked for him. We tracked down the issue to a problem in GDB's documentation: it documents how to do reverse execution, but never mentions until a later section that you can't use reverse execution unless you first turn on process recording.
> 
> Surely it's not intended that one must read the GDB documentation backwards in order to know how to do reverse execution....
> 
> Proposed patch follows. This is just a minor doc patch so I assume no ChangeLog entry is needed.
> 
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index f410d026b8..147c7c0f37 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -6697,8 +6697,11 @@ assumes that the memory and registers that the target reports are in a
>  consistant state, but @value{GDBN} accepts whatever it is given.
>  }.
> 
> -If you are debugging in a target environment that supports
> -reverse execution, @value{GDBN} provides the following commands.
> +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

> 
>  @table @code
>  @kindex reverse-continue
Thanks,
Pedro Alves
  
Eli Zaretskii April 10, 2019, 2:54 p.m. UTC | #2
> From: Pedro Alves <palves@redhat.com>
> 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.

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?
  

Patch

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index f410d026b8..147c7c0f37 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -6697,8 +6697,11 @@  assumes that the memory and registers that the target 
reports are in a
  consistant state, but @value{GDBN} accepts whatever it is given.
  }.

-If you are debugging in a target environment that supports
-reverse execution, @value{GDBN} provides the following commands.
+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.

  @table @code