<!-- ####################################################### -->
<hr />
-<p>
- There are numerous things that can be done to improve the ease with
+<p>There are numerous things that can be done to improve the ease with
which C++ binaries are debugged when using the GNU C++
tool chain. Here are some things to keep in mind when debugging C++
code with GNU tools.
</p>
<h3 class="left"><a name="g++">Compiler flags determine debug info</a></h3>
-<p>
- The default optimizations and debug flags for a libstdc++ build are
+<p>The default optimizations and debug flags for a libstdc++ build are
<code>-g -O2</code>. However, both debug and optimization flags can
be varied to change debugging characteristics. For instance,
turning off all optimization via the <code>-g -O0</code> flag will
in the gcc sources.
</p>
-<p>
- Many other options are available: please see
+<p>Many other options are available: please see
<a href=http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging%20Options> "Options for Debugging Your Program" </a>
in Using the GNU Compiler Collection (GCC) for a complete list.
</p>
<h3 class="left"><a name="lib">Using special flags to make a debug binary</a></h3>
-<p>
- There are two ways to build libstdc++ with debug flags. The first
+<p>There are two ways to build libstdc++ with debug flags. The first
is to run make from the toplevel in a freshly-configured tree with
specialized debug <code>CXXFLAGS</code>, as in <dd> <code> make
CXXFLAGS='-g3 -O0' all </code></dd>
</p>
-<p>
- This quick and dirty approach is often sufficient for quick
+<p>This quick and dirty approach is often sufficient for quick
debugging tasks, but the lack of state can be confusing in the long
term.
</p>
-<p>
- A second approach is to use the configuration flags
+<p>A second approach is to use the configuration flags
</p>
- <dd><code>--enable-debug </code></dd>
+ <dd><code>--enable-debug</code></dd>
-<p>
- and perhaps
-</p>
+<p>and perhaps</p>
- <dd><code>--enable-debug-flags </code></dd>
+ <dd><code>--enable-debug-flags='...'</code></dd>
-<p>
- to create a separate debug build. Both the normal build and the
+<p>to create a separate debug build. Both the normal build and the
debug build will persist, without having to specify
<code>CXXFLAGS</code>, and the debug library will be installed in a
separate directory tree, in <code>(prefix)/lib/debug</code>. For
more information, look at the configuration options document
-<a href=http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html> here</a>
+<a href=http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html>here</a>
</p>
<h3 class="left"><a name="mem">Tips for memory leak hunting</a></h3>
-<p>
- There are various third party memory tracing and debug utilities
+<p>There are various third party memory tracing and debug utilities
that can be used to provide detailed memory allocation information
about C++ code. An exhaustive list of tools is not going to be
attempted, but include <code>mtrace</code>, <code>valgrind</code>,
forget right now.
</p>
-<p>
- Regardless of the memory debugging tool being used, there is one
+<p>Regardless of the memory debugging tool being used, there is one
thing of great importance to keep in mind when debugging C++ code
that uses <code>new</code> and <code>delete</code>:
there are different kinds of allocation schemes that can be used by
document </a> and look specifically for <code>GLIBCPP_FORCE_NEW</code>.
</p>
-<p>
- In a nutshell, the default allocator used by <code>
+<p>In a nutshell, the default allocator used by <code>
std::allocator</code> is a high-performance pool allocator, and can
give the mistaken impression that memory is being leaked, when in
reality the memory is reclaimed after program termination.
</p>
-<p> For valgrind, there are some specific items to keep in mind. First
+<p>For valgrind, there are some specific items to keep in mind. First
of all, use a version of valgrind that will work with current GNU
C++ tools: the first that can do this is valgrind 1.0.4, but later
versions should work at least as well. Second of all, use a
cluttering debug information.
</p>
-<p>
- Fourth, it may be necessary to force deallocation in other
+<p>Fourth, it may be necessary to force deallocation in other
libraries as well, namely the "C" library. On linux, this can be
accomplished with the appropriate use of the
<code>__cxa_atexit</code> or <code>atexit</code> functions.
</p>
<pre>
- #include <cstdlib>
+ #include <cstdlib>
extern "C" void __libc_freeres(void);
int main()
{
atexit(__libc_freeres);
- do_test();
+ do_something();
return 0;
}
</pre>
-<p>
- or, using <code>__cxa_atexit</code>:
-</p>
+<p>or, using <code>__cxa_atexit</code>:</p>
<pre>
extern "C" void __libc_freeres(void);
{
extern void* __dso_handle __attribute__ ((__weak__));
__cxa_atexit((void (*) (void *)) __libc_freeres, NULL,
- &__dso_handle ? __dso_handle : NULL);
+ &__dso_handle ? __dso_handle : NULL);
do_test();
return 0;
}
</pre>
-<p>
- Suggested valgrind flags, given the suggestions above about setting
+<p>Suggested valgrind flags, given the suggestions above about setting
up the runtime environment, library, and test file, might be:
<dd><code>valgrind -v --num-callers=20 --leak-check=yes
<h3 class="left"><a name="gdb">Some gdb strategies</a></h3>
-<p>
- Many options are available for gdb itself: please see <a
-href=http://sources.redhat.com/gdb/current/onlinedocs/gdb_13.html#SEC109>
-"GDB features for C++" </a> in the gdb documentation. Also
-recommended: the other parts of this manual.
-</p>
-<p>
- These settings can either be switched on in at the gdb command
+<p>Many options are available for gdb itself: please see <a
+ href=http://sources.redhat.com/gdb/current/onlinedocs/gdb_13.html#SEC109>
+ "GDB features for C++" </a> in the gdb documentation. Also
+ recommended: the other parts of this manual.
+</p>
+
+<p>These settings can either be switched on in at the gdb command
line, or put into a .gdbint file to establish default debugging
characteristics, like so:
</p>
</pre>
+<h3 class="left"><a name="verbterm">Tracking uncaught exceptions</a></h3>
+<p>The <a href="19_diagnostics/howto.html#4">verbose termination handler</a>
+ gives information about uncaught exceptions which are killing the
+ program. It is described in the linked-to page.
+</p>
+
+
<p>Return <a href="#top">to the top of the page</a> or
<a href="http://gcc.gnu.org/libstdc++/">to the libstdc++ homepage</a>.
</p>
OSDN Git Service
