152 lines
7.4 KiB
HTML
152 lines
7.4 KiB
HTML
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<title>Checkpoint/Restart - Debugging with GDB</title>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html">
|
||
|
|
<meta name="description" content="Debugging with GDB">
|
||
|
|
<meta name="generator" content="makeinfo 4.13">
|
||
|
|
<link title="Top" rel="start" href="index.html#Top">
|
||
|
|
<link rel="up" href="Running.html#Running" title="Running">
|
||
|
|
<link rel="prev" href="Forks.html#Forks" title="Forks">
|
||
|
|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||
|
|
<!--
|
||
|
|
Copyright (C) 1988-2019 Free Software Foundation, Inc.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||
|
|
any later version published by the Free Software Foundation; with the
|
||
|
|
Invariant Sections being ``Free Software'' and ``Free Software Needs
|
||
|
|
Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,''
|
||
|
|
and with the Back-Cover Texts as in (a) below.
|
||
|
|
|
||
|
|
(a) The FSF's Back-Cover Text is: ``You are free to copy and modify
|
||
|
|
this GNU Manual. Buying copies from GNU Press supports the FSF in
|
||
|
|
developing GNU and promoting software freedom.''
|
||
|
|
-->
|
||
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
||
|
|
<style type="text/css"><!--
|
||
|
|
pre.display { font-family:inherit }
|
||
|
|
pre.format { font-family:inherit }
|
||
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallexample { font-size:smaller }
|
||
|
|
pre.smalllisp { font-size:smaller }
|
||
|
|
span.sc { font-variant:small-caps }
|
||
|
|
span.roman { font-family:serif; font-weight:normal; }
|
||
|
|
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||
|
|
--></style>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<div class="node">
|
||
|
|
<a name="Checkpoint%2fRestart"></a>
|
||
|
|
<a name="Checkpoint_002fRestart"></a>
|
||
|
|
<p>
|
||
|
|
Previous: <a rel="previous" accesskey="p" href="Forks.html#Forks">Forks</a>,
|
||
|
|
Up: <a rel="up" accesskey="u" href="Running.html#Running">Running</a>
|
||
|
|
<hr>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h3 class="section">4.12 Setting a <em>Bookmark</em> to Return to Later</h3>
|
||
|
|
|
||
|
|
<p><a name="index-checkpoint-217"></a><a name="index-restart-218"></a><a name="index-bookmark-219"></a><a name="index-snapshot-of-a-process-220"></a><a name="index-rewind-program-state-221"></a>
|
||
|
|
On certain operating systems<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>, <span class="sc">gdb</span> is able to save a <dfn>snapshot</dfn> of a
|
||
|
|
program's state, called a <dfn>checkpoint</dfn>, and come back to it
|
||
|
|
later.
|
||
|
|
|
||
|
|
<p>Returning to a checkpoint effectively undoes everything that has
|
||
|
|
happened in the program since the <code>checkpoint</code> was saved. This
|
||
|
|
includes changes in memory, registers, and even (within some limits)
|
||
|
|
system state. Effectively, it is like going back in time to the
|
||
|
|
moment when the checkpoint was saved.
|
||
|
|
|
||
|
|
<p>Thus, if you're stepping thru a program and you think you're
|
||
|
|
getting close to the point where things go wrong, you can save
|
||
|
|
a checkpoint. Then, if you accidentally go too far and miss
|
||
|
|
the critical statement, instead of having to restart your program
|
||
|
|
from the beginning, you can just go back to the checkpoint and
|
||
|
|
start again from there.
|
||
|
|
|
||
|
|
<p>This can be especially useful if it takes a lot of time or
|
||
|
|
steps to reach the point where you think the bug occurs.
|
||
|
|
|
||
|
|
<p>To use the <code>checkpoint</code>/<code>restart</code> method of debugging:
|
||
|
|
|
||
|
|
|
||
|
|
<a name="index-checkpoint-222"></a>
|
||
|
|
<dl><dt><code>checkpoint</code><dd>Save a snapshot of the debugged program's current execution state.
|
||
|
|
The <code>checkpoint</code> command takes no arguments, but each checkpoint
|
||
|
|
is assigned a small integer id, similar to a breakpoint id.
|
||
|
|
|
||
|
|
<p><a name="index-info-checkpoints-223"></a><br><dt><code>info checkpoints</code><dd>List the checkpoints that have been saved in the current debugging
|
||
|
|
session. For each checkpoint, the following information will be
|
||
|
|
listed:
|
||
|
|
|
||
|
|
<dl>
|
||
|
|
<dt><code>Checkpoint ID</code><br><dt><code>Process ID</code><br><dt><code>Code Address</code><br><dt><code>Source line, or label</code><dd></dl>
|
||
|
|
|
||
|
|
<p><a name="index-restart-_0040var_007bcheckpoint_002did_007d-224"></a><br><dt><code>restart </code><var>checkpoint-id</var><dd>Restore the program state that was saved as checkpoint number
|
||
|
|
<var>checkpoint-id</var>. All program variables, registers, stack frames
|
||
|
|
etc. will be returned to the values that they had when the checkpoint
|
||
|
|
was saved. In essence, gdb will “wind back the clock” to the point
|
||
|
|
in time when the checkpoint was saved.
|
||
|
|
|
||
|
|
<p>Note that breakpoints, <span class="sc">gdb</span> variables, command history etc.
|
||
|
|
are not affected by restoring a checkpoint. In general, a checkpoint
|
||
|
|
only restores things that reside in the program being debugged, not in
|
||
|
|
the debugger.
|
||
|
|
|
||
|
|
<p><a name="index-delete-checkpoint-_0040var_007bcheckpoint_002did_007d-225"></a><br><dt><code>delete checkpoint </code><var>checkpoint-id</var><dd>Delete the previously-saved checkpoint identified by <var>checkpoint-id</var>.
|
||
|
|
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p>Returning to a previously saved checkpoint will restore the user state
|
||
|
|
of the program being debugged, plus a significant subset of the system
|
||
|
|
(OS) state, including file pointers. It won't “un-write” data from
|
||
|
|
a file, but it will rewind the file pointer to the previous location,
|
||
|
|
so that the previously written data can be overwritten. For files
|
||
|
|
opened in read mode, the pointer will also be restored so that the
|
||
|
|
previously read data can be read again.
|
||
|
|
|
||
|
|
<p>Of course, characters that have been sent to a printer (or other
|
||
|
|
external device) cannot be “snatched back”, and characters received
|
||
|
|
from eg. a serial device can be removed from internal program buffers,
|
||
|
|
but they cannot be “pushed back” into the serial pipeline, ready to
|
||
|
|
be received again. Similarly, the actual contents of files that have
|
||
|
|
been changed cannot be restored (at this time).
|
||
|
|
|
||
|
|
<p>However, within those constraints, you actually can “rewind” your
|
||
|
|
program to a previously saved point in time, and begin debugging it
|
||
|
|
again — and you can change the course of events so as to debug a
|
||
|
|
different execution path this time.
|
||
|
|
|
||
|
|
<p><a name="index-checkpoints-and-process-id-226"></a>Finally, there is one bit of internal program state that will be
|
||
|
|
different when you return to a checkpoint — the program's process
|
||
|
|
id. Each checkpoint will have a unique process id (or <var>pid</var>),
|
||
|
|
and each will be different from the program's original <var>pid</var>.
|
||
|
|
If your program has saved a local copy of its process id, this could
|
||
|
|
potentially pose a problem.
|
||
|
|
|
||
|
|
<h4 class="subsection">4.12.1 A Non-obvious Benefit of Using Checkpoints</h4>
|
||
|
|
|
||
|
|
<p>On some systems such as <span class="sc">gnu</span>/Linux, address space randomization
|
||
|
|
is performed on new processes for security reasons. This makes it
|
||
|
|
difficult or impossible to set a breakpoint, or watchpoint, on an
|
||
|
|
absolute address if you have to restart the program, since the
|
||
|
|
absolute location of a symbol will change from one execution to the
|
||
|
|
next.
|
||
|
|
|
||
|
|
<p>A checkpoint, however, is an <em>identical</em> copy of a process.
|
||
|
|
Therefore if you create a checkpoint at (eg.) the start of main,
|
||
|
|
and simply return to that checkpoint instead of restarting the
|
||
|
|
process, you can avoid the effects of address randomization and
|
||
|
|
your symbols will all stay in the same place.
|
||
|
|
|
||
|
|
<div class="footnote">
|
||
|
|
<hr>
|
||
|
|
<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> Currently, only
|
||
|
|
<span class="sc">gnu</span>/Linux.</p>
|
||
|
|
|
||
|
|
<hr></div>
|
||
|
|
|
||
|
|
</body></html>
|
||
|
|
|