OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-stable/] [gcc-4.5.1/] [libstdc++-v3/] [doc/] [html/] [manual/] [debug.html] - Blame information for rev 841

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 424 jeremybenn 
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
2 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Debugging Support</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><meta name="keywords" content="&#10;      C++&#10;    , &#10;      debug&#10;    " /><meta name="keywords" content="&#10;      ISO C++&#10;    , &#10;      library&#10;    " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_exceptions.html" title="Exceptions" /><link rel="next" href="support.html" title="Part II.  Support" /></head><body><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="support.html">Next</a></td></tr></table><hr /></div><div class="sect1" title="Debugging Support"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.debug"></a>Debugging Support</h2></div></div></div><p>
4 
  There are numerous things that can be done to improve the ease with
5 
  which C++ binaries are debugged when using the GNU tool chain. Here
6 
  are some of them.
7 
</p><div class="sect2" title="Using g++"><div class="titlepage"><div><div><h3 class="title"><a id="debug.compiler"></a>Using <span class="command"><strong>g++</strong></span></h3></div></div></div><p>
8 
    Compiler flags determine how debug information is transmitted
9 
    between compilation and debug or analysis tools.
10 
  </p><p>
11 
    The default optimizations and debug flags for a libstdc++ build
12 
    are <code class="code">-g -O2</code>. However, both debug and optimization
13 
    flags can be varied to change debugging characteristics. For
14 
    instance, turning off all optimization via the <code class="code">-g -O0
15 
    -fno-inline</code> flags will disable inlining and optimizations,
16 
    and add debugging information, so that stepping through all functions,
17 
    (including inlined constructors and destructors) is possible. In
18 
    addition, <code class="code">-fno-eliminate-unused-debug-types</code> can be
19 
    used when additional debug information, such as nested class info,
20 
    is desired.
21 
</p><p>
22 
  Or, the debug format that the compiler and debugger use to
23 
  communicate information about source constructs can be changed via
24 
  <code class="code">-gdwarf-2</code> or <code class="code">-gstabs</code> flags: some debugging
25 
  formats permit more expressive type and scope information to be
26 
  shown in gdb. Expressiveness can be enhanced by flags like
27 
  <code class="code">-g3</code>. The default debug information for a particular
28 
  platform can be identified via the value set by the
29 
  PREFERRED_DEBUGGING_TYPE macro in the gcc sources.
30 
</p><p>
31 
  Many other options are available: please see <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging%20Options" target="_top">"Options
32 
  for Debugging Your Program"</a> in Using the GNU Compiler
33 
  Collection (GCC) for a complete list.
34 
</p></div><div class="sect2" title="Debug Versions of Library Binary Files"><div class="titlepage"><div><div><h3 class="title"><a id="debug.req"></a>Debug Versions of Library Binary Files</h3></div></div></div><p>
35 
  If you would like debug symbols in libstdc++, there are two ways to
36 
  build libstdc++ with debug flags. The first is to run make from the
37 
  toplevel in a freshly-configured tree with
38 
</p><pre class="programlisting">
39 
     --enable-libstdcxx-debug
40 
</pre><p>and perhaps</p><pre class="programlisting">
41 
     --enable-libstdcxx-debug-flags='...'
42 
</pre><p>
43 
  to create a separate debug build. Both the normal build and the
44 
  debug build will persist, without having to specify
45 
  <code class="code">CXXFLAGS</code>, and the debug library will be installed in a
46 
  separate directory tree, in <code class="code">(prefix)/lib/debug</code>. For
47 
  more information, look at the <a class="link" href="configure.html" title="Configure">configuration</a> section.
48 
</p><p>
49 
  A second approach is to use the configuration flags
50 
</p><pre class="programlisting">
51 
     make CXXFLAGS='-g3 -fno-inline -O0' all
52 
</pre><p>
53 
  This quick and dirty approach is often sufficient for quick
54 
  debugging tasks, when you cannot or don't want to recompile your
55 
  application to use the <a class="link" href="debug_mode.html" title="Chapter 30. Debug Mode">debug mode</a>.</p></div><div class="sect2" title="Memory Leak Hunting"><div class="titlepage"><div><div><h3 class="title"><a id="debug.memory"></a>Memory Leak Hunting</h3></div></div></div><p>
56 
  There are various third party memory tracing and debug utilities
57 
  that can be used to provide detailed memory allocation information
58 
  about C++ code. An exhaustive list of tools is not going to be
59 
  attempted, but includes <code class="code">mtrace</code>, <code class="code">valgrind</code>,
60 
  <code class="code">mudflap</code>, and the non-free commercial product
61 
  <code class="code">purify</code>. In addition, <code class="code">libcwd</code> has a
62 
  replacement for the global new and delete operators that can track
63 
  memory allocation and deallocation and provide useful memory
64 
  statistics.
65 
</p><p>
66 
  Regardless of the memory debugging tool being used, there is one
67 
  thing of great importance to keep in mind when debugging C++ code
68 
  that uses <code class="code">new</code> and <code class="code">delete</code>: there are
69 
  different kinds of allocation schemes that can be used by <code class="code">
70 
  std::allocator </code>. For implementation details, see the <a class="link" href="ext_allocators.html#manual.ext.allocator.mt" title="mt_allocator">mt allocator</a> documentation and
71 
  look specifically for <code class="code">GLIBCXX_FORCE_NEW</code>.
72 
</p><p>
73 
  In a nutshell, the default allocator used by <code class="code">
74 
  std::allocator</code> is a high-performance pool allocator, and can
75 
  give the mistaken impression that in a suspect executable, memory is
76 
  being leaked, when in reality the memory "leak" is a pool being used
77 
  by the library's allocator and is reclaimed after program
78 
  termination.
79 
</p><p>
80 
  For valgrind, there are some specific items to keep in mind. First
81 
  of all, use a version of valgrind that will work with current GNU
82 
  C++ tools: the first that can do this is valgrind 1.0.4, but later
83 
  versions should work at least as well. Second of all, use a
84 
  completely unoptimized build to avoid confusing valgrind. Third, use
85 
  GLIBCXX_FORCE_NEW to keep extraneous pool allocation noise from
86 
  cluttering debug information.
87 
</p><p>
88 
  Fourth, it may be necessary to force deallocation in other libraries
89 
  as well, namely the "C" library. On linux, this can be accomplished
90 
  with the appropriate use of the <code class="code">__cxa_atexit</code> or
91 
  <code class="code">atexit</code> functions.
92 
</p><pre class="programlisting">
93 
   #include &lt;cstdlib&gt;
94 
 
95 
   extern "C" void __libc_freeres(void);
96 
 
97 
   void do_something() { }
98 
 
99 
   int main()
100 
   {
101 
     atexit(__libc_freeres);
102 
     do_something();
103 
     return 0;
104 
   }
105 
</pre><p>or, using <code class="code">__cxa_atexit</code>:</p><pre class="programlisting">
106 
   extern "C" void __libc_freeres(void);
107 
   extern "C" int __cxa_atexit(void (*func) (void *), void *arg, void *d);
108 
 
109 
   void do_something() { }
110 
 
111 
   int main()
112 
   {
113 
      extern void* __dso_handle __attribute__ ((__weak__));
114 
      __cxa_atexit((void (*) (void *)) __libc_freeres, NULL,
115 
                   &amp;__dso_handle ? __dso_handle : NULL);
116 
      do_test();
117 
      return 0;
118 
   }
119 
</pre><p>
120 
  Suggested valgrind flags, given the suggestions above about setting
121 
  up the runtime environment, library, and test file, might be:
122 
</p><pre class="programlisting">
123 
   valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
124 
</pre></div><div class="sect2" title="Using gdb"><div class="titlepage"><div><div><h3 class="title"><a id="debug.gdb"></a>Using <span class="command"><strong>gdb</strong></span></h3></div></div></div><p>
125 
  </p><p>
126 
  Many options are available for gdb itself: please see <a class="ulink" href="http://sources.redhat.com/gdb/current/onlinedocs/gdb_13.html#SEC125" target="_top">
127 
  "GDB features for C++" </a> in the gdb documentation. Also
128 
  recommended: the other parts of this manual.
129 
</p><p>
130 
  These settings can either be switched on in at the gdb command line,
131 
  or put into a .gdbint file to establish default debugging
132 
  characteristics, like so:
133 
</p><pre class="programlisting">
134 
   set print pretty on
135 
   set print object on
136 
   set print static-members on
137 
   set print vtbl on
138 
   set print demangle on
139 
   set demangle-style gnu-v3
140 
</pre><p>
141 
  Starting with version 7.0, GDB includes support for writing
142 
  pretty-printers in Python.  Pretty printers for STL classes are
143 
  distributed with GCC from version 4.5.0.  The most recent version of
144 
  these printers are always found in libstdc++ svn repository.
145 
  To enable these printers, check-out the latest printers to a local
146 
  directory:
147 
</p><pre class="programlisting">
148 
  svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
149 
</pre><p>
150 
  Next, add the following section to your ~/.gdbinit  The path must
151 
  match the location where the Python module above was checked-out.
152 
  So if checked out to: /home/maude/gdb_printers/, the path would be as
153 
  written in the example below.
154 
</p><pre class="programlisting">
155 
  python
156 
  import sys
157 
  sys.path.insert(0, '/home/maude/gdb_printers/python')
158 
  from libstdcxx.v6.printers import register_libstdcxx_printers
159 
  register_libstdcxx_printers (None)
160 
  end
161 
</pre><p>
162 
  The path should be the only element that needs to be adjusted in the
163 
  example.  Once loaded, STL classes that the printers support
164 
  should print in a more human-readable format.  To print the classes
165 
  in the old style, use the /r (raw) switch in the print command
166 
  (i.e., print /r foo).  This will print the classes as if the Python
167 
  pretty-printers were not loaded.
168 
</p><p>
169 
  For additional information on STL support and GDB please visit:
170 
  <a class="ulink" href="http://sourceware.org/gdb/wiki/STLSupport" target="_top"> "GDB Support
171 
  for STL" </a> in the GDB wiki.  Additionally, in-depth
172 
  documentation and discussion of the pretty printing feature can be
173 
  found in "Pretty Printing" node in the GDB manual.  You can find
174 
  on-line versions of the GDB user manual in GDB's homepage, at
175 
  <a class="ulink" href="http://sourceware.org/gdb/" target="_top"> "GDB: The GNU Project
176 
  Debugger" </a>.
177 
</p></div><div class="sect2" title="Tracking uncaught exceptions"><div class="titlepage"><div><div><h3 class="title"><a id="debug.exceptions"></a>Tracking uncaught exceptions</h3></div></div></div><p>
178 
  The <a class="link" href="verbose_termination.html" title="Verbose Terminate Handler">verbose
179 
  termination handler</a> gives information about uncaught
180 
  exceptions which are killing the program.  It is described in the
181 
  linked-to page.
182 
</p></div><div class="sect2" title="Debug Mode"><div class="titlepage"><div><div><h3 class="title"><a id="debug.debug_mode"></a>Debug Mode</h3></div></div></div><p> The <a class="link" href="debug_mode.html" title="Chapter 30. Debug Mode">Debug Mode</a>
183 
  has compile and run-time checks for many containers.
184 
  </p></div><div class="sect2" title="Compile Time Checking"><div class="titlepage"><div><div><h3 class="title"><a id="debug.compile_time_checks"></a>Compile Time Checking</h3></div></div></div><p> The <a class="link" href="ext_compile_checks.html" title="Chapter 29. Compile Time Checks">Compile-Time
185 
  Checks</a> Extension has compile-time checks for many algorithms.
186 
  </p></div><div class="sect2" title="Profile-based Performance Analysis"><div class="titlepage"><div><div><h3 class="title"><a id="debug.profile_mode"></a>Profile-based Performance Analysis</h3></div></div></div><p> The <a class="link" href="profile_mode.html" title="Chapter 32. Profile Mode">Profile-based
187 
  Performance Analysis</a> Extension has performance checks for many
188 
  algorithms.
189 
  </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="support.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Exceptions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part II. 
190 
  Support
191 
 
192 
</td></tr></table></div></body></html>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.