diff options
| author | Phil Edwards <pme@gcc.gnu.org> | 2002-12-26 21:14:19 +0000 |
|---|---|---|
| committer | Phil Edwards <pme@gcc.gnu.org> | 2002-12-26 21:14:19 +0000 |
| commit | 3642a94924510f7e7220aea6aefebc7372d59d8b (patch) | |
| tree | f66065999fa229c8f6d604e81b12a0d16ef6c490 /libstdc++-v3/docs/html/debug.html | |
| parent | f411c849f0c36e909d82823c517fd6c6c9a457e2 (diff) | |
| download | gcc-3642a94924510f7e7220aea6aefebc7372d59d8b.zip gcc-3642a94924510f7e7220aea6aefebc7372d59d8b.tar.gz gcc-3642a94924510f7e7220aea6aefebc7372d59d8b.tar.bz2 | |
eh_term_handler.cc: Add comment about embedded systems.
2002-12-26 Phil Edwards <pme@gcc.gnu.org>
* libsupc++/eh_term_handler.cc: Add comment about embedded systems.
* docs/html/debug.html: Cosmetic and HTML changes. Point to
verb-term notes.
* docs/html/documentation.html: Link to the FAQ.
* docs/html/17_intro/howto.html: Mention use of isatty(3).
* docs/html/19_diagnostics/howto.html: Update verb-term description.
From-SVN: r60528
Diffstat (limited to 'libstdc++-v3/docs/html/debug.html')
| -rw-r--r-- | libstdc++-v3/docs/html/debug.html | 80 |
1 files changed, 35 insertions, 45 deletions
diff --git a/libstdc++-v3/docs/html/debug.html b/libstdc++-v3/docs/html/debug.html index 73d592f..ff20d24 100644 --- a/libstdc++-v3/docs/html/debug.html +++ b/libstdc++-v3/docs/html/debug.html @@ -28,16 +28,14 @@ <!-- ####################################################### --> <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 @@ -53,53 +51,45 @@ 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>, @@ -108,8 +98,7 @@ 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 @@ -118,14 +107,13 @@ 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 @@ -134,15 +122,14 @@ 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); @@ -151,15 +138,13 @@ 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); @@ -171,14 +156,13 @@ { 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 @@ -187,14 +171,13 @@ <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> @@ -209,6 +192,13 @@ recommended: the other parts of this manual. </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> |