Re: reverse execution part of the manual is written backwards

[Eli Zaretskii <eliz at gnu dot org>]

> 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?