| Message ID | 159903462227.28509.8201860642659050083.stgit@pasha-ThinkPad-X280 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Reverse debugging | expand |
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>
On 08.09.2020 14:27, Alex Bennée wrote: > > 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. Ok, I renamed and moved replay.txt, but havent't found how to build the docs. Can you give any hints?
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. + Replay log format -----------------