+++ /dev/null
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE html
- PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="AUTHOR" content="bkoz@gcc.gnu.org (Benjamin Kosnik)" />
- <meta name="KEYWORDS" content="c++, libstdc++, gdb, g++, debug" />
- <meta name="DESCRIPTION" content="Debugging C++ binaries" />
- <meta name="GENERATOR" content="vi and ten fingers" />
- <title>Debugging schemes and strategies</title>
-<link rel="StyleSheet" href="lib3styles.css" />
-</head>
-<body>
-
-<h1 class="centered"><a name="top">Debugging schemes and strategies</a></h1>
-
-<p class="fineprint"><em>
-<p>The latest version of this document is always available at
- <a href="http://gcc.gnu.org/onlinedocs/libstdc++/debug.html">
- http://gcc.gnu.org/onlinedocs/libstdc++/debug.html</a>.
-</p>
-
-<p>To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
-</p>
-</em></p>
-
-<!-- ####################################################### -->
-<hr />
-<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
- <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
- disable inlining, so that stepping through all functions, including
- inlined constructors and destructors, is possible. Or, the debug
- format that the compiler and debugger use to communicate
- information about source constructs can be changed via <code>
- -gdwarf-2 </code> or <code> -gstabs </code> flags: some debugging
- formats permit more expressive type and scope information to be
- shown in gdb.
- The default debug information for a particular platform can be
- identified via the value set by the PREFERRED_DEBUGGING_TYPE macro
- in the gcc sources.
-</p>
-
-<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
- 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
- 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>
-
- <dd><code>--enable-debug</code></dd>
-
-<p>and perhaps</p>
-
- <dd><code>--enable-debug-flags='...'</code></dd>
-
-<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>
-</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
- 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>,
- <code>mudflap</code>, and <code>purify</code>. Also highly
- recommended are <code>libcwd</code> and some other one that I
- forget right now.
-</p>
-
-<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
- <code> std::allocator </code>. For implementation details, see this
- <a href=http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3>
- document </a> and look specifically for <code>GLIBCPP_FORCE_NEW</code>.
-</p>
-
-<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
- 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
- completely unoptimized build to avoid confusing valgrind. Third,
- use GLIBCPP_FORCE_NEW to keep extraneous pool allocation noise from
- cluttering debug information.
-</p>
-
-<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>
-
- extern "C" void __libc_freeres(void);
-
- void do_something() { }
-
- int main()
- {
- atexit(__libc_freeres);
- do_something();
- return 0;
- }
-</pre>
-
-
-<p>or, using <code>__cxa_atexit</code>:</p>
-
-<pre>
- extern "C" void __libc_freeres(void);
- extern "C" int __cxa_atexit(void (*func) (void *), void *arg, void *d);
-
- void do_something() { }
-
- int main()
- {
- extern void* __dso_handle __attribute__ ((__weak__));
- __cxa_atexit((void (*) (void *)) __libc_freeres, NULL,
- &__dso_handle ? __dso_handle : NULL);
- do_test();
- return 0;
- }
-</pre>
-
-<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
- --leak-resolution=high --show-reachable=yes a.out</code></dd>
-</p>
-
-
-<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
- line, or put into a .gdbint file to establish default debugging
- characteristics, like so:
-</p>
-
-<pre>
- set print pretty on
- set print object on
- set print static-members on
- set print vtbl on
- set print demangle on
- set demangle-style gnu-v3
-</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>
-
-
-<!-- ####################################################### -->
-
-<hr />
-<p class="fineprint"><em>
-See <a href="17_intro/license.html">license.html</a> for copying conditions.
-Comments and suggestions are welcome, and may be sent to
-<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
-</em></p>
-
-
-</body>
-</html>
projects / msp430-gcc.git / blobdiff