*: Regenerate.
[gcc.git] / libstdc++-v3 / doc / html / manual / debug.html
1 <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Debugging Support</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"><meta name="keywords" content="
2 C++
3 ,
4 debug
5 "><meta name="keywords" content="
6 ISO C++
7 ,
8 library
9 "><meta name="keywords" content="
10 ISO C++
11 ,
12 runtime
13 ,
14 library
15 "><link rel="home" href="../index.html" title="The GNU C++ Library"><link rel="up" href="using.html" title="Chapter 3. Using"><link rel="prev" href="using_exceptions.html" title="Exceptions"><link rel="next" href="bk01pt02.html" title="Part II.  Standard Contents"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Debugging Support</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_exceptions.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02.html">Next</a></td></tr></table><hr></div><div class="section" title="Debugging Support"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="manual.intro.using.debug"></a>Debugging Support</h2></div></div></div><p>
16 There are numerous things that can be done to improve the ease with
17 which C++ binaries are debugged when using the GNU tool chain. Here
18 are some of them.
19 </p><div class="section" title="Using g++"><div class="titlepage"><div><div><h3 class="title"><a name="debug.compiler"></a>Using <span class="command"><strong>g++</strong></span></h3></div></div></div><p>
20 Compiler flags determine how debug information is transmitted
21 between compilation and debug or analysis tools.
22 </p><p>
23 The default optimizations and debug flags for a libstdc++ build
24 are <code class="code">-g -O2</code>. However, both debug and optimization
25 flags can be varied to change debugging characteristics. For
26 instance, turning off all optimization via the <code class="code">-g -O0
27 -fno-inline</code> flags will disable inlining and optimizations,
28 and add debugging information, so that stepping through all functions,
29 (including inlined constructors and destructors) is possible. In
30 addition, <code class="code">-fno-eliminate-unused-debug-types</code> can be
31 used when additional debug information, such as nested class info,
32 is desired.
33 </p><p>
34 Or, the debug format that the compiler and debugger use to
35 communicate information about source constructs can be changed via
36 <code class="code">-gdwarf-2</code> or <code class="code">-gstabs</code> flags: some debugging
37 formats permit more expressive type and scope information to be
38 shown in GDB. Expressiveness can be enhanced by flags like
39 <code class="code">-g3</code>. The default debug information for a particular
40 platform can be identified via the value set by the
41 PREFERRED_DEBUGGING_TYPE macro in the gcc sources.
42 </p><p>
43 Many other options are available: please see <a class="link" href="http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging%20Options" target="_top">"Options
44 for Debugging Your Program"</a> in Using the GNU Compiler
45 Collection (GCC) for a complete list.
46 </p></div><div class="section" title="Debug Versions of Library Binary Files"><div class="titlepage"><div><div><h3 class="title"><a name="debug.req"></a>Debug Versions of Library Binary Files</h3></div></div></div><p>
47 If you would like debug symbols in libstdc++, there are two ways to
48 build libstdc++ with debug flags. The first is to create a separate
49 debug build by running make from the top-level of a tree
50 freshly-configured with
51 </p><pre class="programlisting">
52 --enable-libstdcxx-debug
53 </pre><p>and perhaps</p><pre class="programlisting">
54 --enable-libstdcxx-debug-flags='...'
55 </pre><p>
56 Both the normal build and the debug build will persist, without
57 having to specify <code class="code">CXXFLAGS</code>, and the debug library will
58 be installed in a separate directory tree, in <code class="code">(prefix)/lib/debug</code>.
59 For more information, look at the
60 <a class="link" href="configure.html" title="Configure">configuration</a> section.
61 </p><p>
62 A second approach is to use the configuration flags
63 </p><pre class="programlisting">
64 make CXXFLAGS='-g3 -fno-inline -O0' all
65 </pre><p>
66 This quick and dirty approach is often sufficient for quick
67 debugging tasks, when you cannot or don't want to recompile your
68 application to use the <a class="link" href="debug_mode.html" title="Chapter 17. Debug Mode">debug mode</a>.</p></div><div class="section" title="Memory Leak Hunting"><div class="titlepage"><div><div><h3 class="title"><a name="debug.memory"></a>Memory Leak Hunting</h3></div></div></div><p>
69 There are various third party memory tracing and debug utilities
70 that can be used to provide detailed memory allocation information
71 about C++ code. An exhaustive list of tools is not going to be
72 attempted, but includes <code class="code">mtrace</code>, <code class="code">valgrind</code>,
73 <code class="code">mudflap</code>, and the non-free commercial product
74 <code class="code">purify</code>. In addition, <code class="code">libcwd</code> has a
75 replacement for the global new and delete operators that can track
76 memory allocation and deallocation and provide useful memory
77 statistics.
78 </p><p>
79 Regardless of the memory debugging tool being used, there is one
80 thing of great importance to keep in mind when debugging C++ code
81 that uses <code class="code">new</code> and <code class="code">delete</code>: there are
82 different kinds of allocation schemes that can be used by <code class="code">
83 std::allocator</code>. For implementation details, see the <a class="link" href="mt_allocator.html" title="Chapter 20. The mt_allocator">mt allocator</a> documentation and
84 look specifically for <code class="code">GLIBCXX_FORCE_NEW</code>.
85 </p><p>
86 In a nutshell, the optional <code class="classname">mt_allocator</code>
87 is a high-performance pool allocator, and can
88 give the mistaken impression that in a suspect executable, memory is
89 being leaked, when in reality the memory "leak" is a pool being used
90 by the library's allocator and is reclaimed after program
91 termination.
92 </p><p>
93 For valgrind, there are some specific items to keep in mind. First
94 of all, use a version of valgrind that will work with current GNU
95 C++ tools: the first that can do this is valgrind 1.0.4, but later
96 versions should work at least as well. Second of all, use a
97 completely unoptimized build to avoid confusing valgrind. Third, use
98 GLIBCXX_FORCE_NEW to keep extraneous pool allocation noise from
99 cluttering debug information.
100 </p><p>
101 Fourth, it may be necessary to force deallocation in other libraries
102 as well, namely the "C" library. On linux, this can be accomplished
103 with the appropriate use of the <code class="code">__cxa_atexit</code> or
104 <code class="code">atexit</code> functions.
105 </p><pre class="programlisting">
106 #include &lt;cstdlib&gt;
107
108 extern "C" void __libc_freeres(void);
109
110 void do_something() { }
111
112 int main()
113 {
114 atexit(__libc_freeres);
115 do_something();
116 return 0;
117 }
118 </pre><p>or, using <code class="code">__cxa_atexit</code>:</p><pre class="programlisting">
119 extern "C" void __libc_freeres(void);
120 extern "C" int __cxa_atexit(void (*func) (void *), void *arg, void *d);
121
122 void do_something() { }
123
124 int main()
125 {
126 extern void* __dso_handle __attribute__ ((__weak__));
127 __cxa_atexit((void (*) (void *)) __libc_freeres, NULL,
128 &amp;__dso_handle ? __dso_handle : NULL);
129 do_test();
130 return 0;
131 }
132 </pre><p>
133 Suggested valgrind flags, given the suggestions above about setting
134 up the runtime environment, library, and test file, might be:
135 </p><pre class="programlisting">
136 valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
137 </pre></div><div class="section" title="Data Race Hunting"><div class="titlepage"><div><div><h3 class="title"><a name="debug.races"></a>Data Race Hunting</h3></div></div></div><p>
138 All synchronization primitives used in the library internals need to be
139 understood by race detectors so that they do not produce false reports.
140 </p><p>
141 Two annotation macros are used to explain low-level synchronization
142 to race detectors:
143 <code class="code">_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE()</code> and
144 <code class="code"> _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER()</code>.
145 By default, these macros are defined empty -- anyone who wants
146 to use a race detector needs to redefine them to call an
147 appropriate API.
148 Since these macros are empty by default when the library is built,
149 redefining them will only affect inline functions and template
150 instantiations which are compiled in user code. This allows annotation
151 of templates such as <code class="code">shared_ptr</code>, but not code which is
152 only instantiated in the library. Code which is only instantiated in
153 the library needs to be recompiled with the annotation macros defined.
154 That can be done by rebuilding the entire
155 <code class="filename">libstdc++.so</code> file but a simpler
156 alternative exists for ELF platforms such as GNU/Linux, because ELF
157 symbol interposition allows symbols defined in the shared library to be
158 overridden by symbols with the same name that appear earlier in the
159 runtime search path. This means you only need to recompile the functions
160 that are affected by the annotation macros, which can be done by
161 recompiling individual files.
162 Annotating <code class="code">std::string</code> and <code class="code">std::wstring</code>
163 reference counting can be done by disabling extern templates (by defining
164 <code class="code">_GLIBCXX_EXTERN_TEMPLATE=-1</code>) or by rebuilding the
165 <code class="filename">src/string-inst.cc</code> file.
166 Annotating the remaining atomic operations (at the time of writing these
167 are in <code class="code">ios_base::Init::~Init</code>, <code class="code">locale::_Impl</code>,
168 <code class="code">locale::facet</code> and <code class="code">thread::_M_start_thread</code>)
169 requires rebuilding the relevant source files.
170 </p><p>
171 The approach described above is known to work with the following race
172 detection tools:
173 <a class="link" href="http://valgrind.org/docs/manual/drd-manual.html" target="_top">
174 DRD</a>,
175 <a class="link" href="http://valgrind.org/docs/manual/hg-manual.html" target="_top">
176 Helgrind</a>, and
177 <a class="link" href="http://code.google.com/p/data-race-test" target="_top">
178 ThreadSanitizer</a>.
179 </p><p>
180 With DRD, Helgrind and ThreadSanitizer you will need to define
181 the macros like this:
182 </p><pre class="programlisting">
183 #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(A) ANNOTATE_HAPPENS_BEFORE(A)
184 #define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(A) ANNOTATE_HAPPENS_AFTER(A)
185 </pre><p>
186 Refer to the documentation of each particular tool for details.
187 </p></div><div class="section" title="Using gdb"><div class="titlepage"><div><div><h3 class="title"><a name="debug.gdb"></a>Using <span class="command"><strong>gdb</strong></span></h3></div></div></div><p>
188 </p><p>
189 Many options are available for GDB itself: please see <a class="link" href="http://sources.redhat.com/gdb/current/onlinedocs/gdb/" target="_top">
190 "GDB features for C++" </a> in the GDB documentation. Also
191 recommended: the other parts of this manual.
192 </p><p>
193 These settings can either be switched on in at the GDB command line,
194 or put into a .gdbint file to establish default debugging
195 characteristics, like so:
196 </p><pre class="programlisting">
197 set print pretty on
198 set print object on
199 set print static-members on
200 set print vtbl on
201 set print demangle on
202 set demangle-style gnu-v3
203 </pre><p>
204 Starting with version 7.0, GDB includes support for writing
205 pretty-printers in Python. Pretty printers for STL classes are
206 distributed with GCC from version 4.5.0. The most recent version of
207 these printers are always found in libstdc++ svn repository.
208 To enable these printers, check-out the latest printers to a local
209 directory:
210 </p><pre class="programlisting">
211 svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
212 </pre><p>
213 Next, add the following section to your ~/.gdbinit The path must
214 match the location where the Python module above was checked-out.
215 So if checked out to: /home/maude/gdb_printers/, the path would be as
216 written in the example below.
217 </p><pre class="programlisting">
218 python
219 import sys
220 sys.path.insert(0, '/home/maude/gdb_printers/python')
221 from libstdcxx.v6.printers import register_libstdcxx_printers
222 register_libstdcxx_printers (None)
223 end
224 </pre><p>
225 The path should be the only element that needs to be adjusted in the
226 example. Once loaded, STL classes that the printers support
227 should print in a more human-readable format. To print the classes
228 in the old style, use the /r (raw) switch in the print command
229 (i.e., print /r foo). This will print the classes as if the Python
230 pretty-printers were not loaded.
231 </p><p>
232 For additional information on STL support and GDB please visit:
233 <a class="link" href="http://sourceware.org/gdb/wiki/STLSupport" target="_top"> "GDB Support
234 for STL" </a> in the GDB wiki. Additionally, in-depth
235 documentation and discussion of the pretty printing feature can be
236 found in "Pretty Printing" node in the GDB manual. You can find
237 on-line versions of the GDB user manual in GDB's homepage, at
238 <a class="link" href="http://sourceware.org/gdb/" target="_top"> "GDB: The GNU Project
239 Debugger" </a>.
240 </p></div><div class="section" title="Tracking uncaught exceptions"><div class="titlepage"><div><div><h3 class="title"><a name="debug.exceptions"></a>Tracking uncaught exceptions</h3></div></div></div><p>
241 The <a class="link" href="termination.html#support.termination.verbose" title="Verbose Terminate Handler">verbose
242 termination handler</a> gives information about uncaught
243 exceptions which are killing the program. It is described in the
244 linked-to page.
245 </p></div><div class="section" title="Debug Mode"><div class="titlepage"><div><div><h3 class="title"><a name="debug.debug_mode"></a>Debug Mode</h3></div></div></div><p> The <a class="link" href="debug_mode.html" title="Chapter 17. Debug Mode">Debug Mode</a>
246 has compile and run-time checks for many containers.
247 </p></div><div class="section" title="Compile Time Checking"><div class="titlepage"><div><div><h3 class="title"><a name="debug.compile_time_checks"></a>Compile Time Checking</h3></div></div></div><p> The <a class="link" href="ext_compile_checks.html" title="Chapter 16. Compile Time Checks">Compile-Time
248 Checks</a> Extension has compile-time checks for many algorithms.
249 </p></div><div class="section" title="Profile-based Performance Analysis"><div class="titlepage"><div><div><h3 class="title"><a name="debug.profile_mode"></a>Profile-based Performance Analysis</h3></div></div></div><p> The <a class="link" href="profile_mode.html" title="Chapter 19. Profile Mode">Profile-based
250 Performance Analysis</a> Extension has performance checks for many
251 algorithms.
252 </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_exceptions.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Exceptions </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Part II. 
253 Standard Contents
254 </td></tr></table></div></body></html>