Re: [PATCH v3 13/15] replay: describe reverse debugging in docs/replay.txt

["Alex Bennée" <alex.bennee@linaro.org>]

Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:

> From: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
>
> This patch updates the documentation and describes usage of the reverse
> debugging in QEMU+GDB.
>
> Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
> ---
>  docs/replay.txt |   33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)

Minor aside - it is probably worth having a separate patch to convert
this file into an .rst and put it in the docs/system folder so we can
properly incorporate it into the user documentation. 

>
> diff --git a/docs/replay.txt b/docs/replay.txt
> index 70c27edb36..18d6169f3b 100644
> --- a/docs/replay.txt
> +++ b/docs/replay.txt
> @@ -294,6 +294,39 @@ for recording and replaying must contain identical number of ports in record
>  and replay modes, but their backends may differ.
>  E.g., '-serial stdio' in record mode, and '-serial null' in replay mode.
>  
> +Reverse debugging
> +-----------------
> +
> +Reverse debugging allows "executing" the program in reverse direction.
> +GDB remote protocol supports "reverse step" and "reverse continue"
> +commands. The first one steps single instruction backwards in time,
> +and the second one finds the last breakpoint in the past.
> +
> +Recorded executions may be used to enable reverse debugging. QEMU can't
> +execute the code in backwards direction, but can load a snapshot and
> +replay forward to find the desired position or breakpoint.
> +
> +The following GDB commands are supported:
> + - reverse-stepi (or rsi) - step one instruction backwards
> + - reverse-continue (or rc) - find last breakpoint in the past
> +
> +Reverse step loads the nearest snapshot and replays the execution until
> +the required instruction is met.
> +
> +Reverse continue may include several passes of examining the execution
> +between the snapshots. Each of the passes include the following steps:
> + 1. loading the snapshot
> + 2. replaying to examine the breakpoints
> + 3. if breakpoint or watchpoint was met
> +    - loading the snaphot again
> +    - replaying to the required breakpoint
> + 4. else
> +    - proceeding to the p.1 with the earlier snapshot
> +
> +Therefore usage of the reverse debugging requires at least one snapshot
> +created in advance. See the "Snapshotting" section to learn about running
> +record/replay and creating the snapshot in these modes.

I would explicitly state you need:

  - a block device for storing VM snapshots (independent of storage
    devices you may have)
  - to specify the starting rrsnapshot in both the record and replay runs

Otherwise:

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée