- The latest version of this document is always available at
-
- http://gcc.gnu.org/onlinedocs/libstdc++/debug.html.
- To the libstdc++-v3 homepage.
-
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. -
- -The default optimizations and debug flags for a libstdc++ build are
- -g -O2. However, both debug and optimization flags can
- be varied to change debugging characteristics. For instance,
- turning off all optimization via the -g -O0 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
- -gdwarf-2 or -gstabs 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.
-
Many other options are available: please see - "Options for Debugging Your Program" - in Using the GNU Compiler Collection (GCC) for a complete list. -
- - -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 CXXFLAGS, as in
make
- CXXFLAGS='-g3 -O0' all This quick and dirty approach is often sufficient for quick - debugging tasks, but the lack of state can be confusing in the long - term. -
- -A second approach is to use the configuration flags -
- ---enable-debugand perhaps
- ---enable-debug-flags='...'to create a separate debug build. Both the normal build and the
- debug build will persist, without having to specify
- CXXFLAGS, and the debug library will be installed in a
- separate directory tree, in (prefix)/lib/debug. For
- more information, look at the configuration options document
-here
-
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 mtrace, valgrind,
- mudflap, and purify. Also highly
- recommended are libcwd and some other one that I
- forget right now.
-
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 new and delete:
- there are different kinds of allocation schemes that can be used by
- std::allocator . For implementation details, see this
-
- document and look specifically for GLIBCPP_FORCE_NEW.
-
In a nutshell, the default allocator used by
- std::allocator 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.
-
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. -
- -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
- __cxa_atexit or atexit functions.
-
- #include <cstdlib>
-
- extern "C" void __libc_freeres(void);
-
- void do_something() { }
-
- int main()
- {
- atexit(__libc_freeres);
- do_something();
- return 0;
- }
-
-
-
-or, using __cxa_atexit:
- 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;
- }
-
-
-Suggested valgrind flags, given the suggestions above about setting - up the runtime environment, library, and test file, might be: - -
valgrind -v --num-callers=20 --leak-check=yes
- --leak-resolution=high --show-reachable=yes a.outMany options are available for gdb itself: please see - "GDB features for C++" in the gdb documentation. Also - recommended: the other parts of this manual. -
- -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: -
- -- 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 -- - -
The verbose termination handler - gives information about uncaught exceptions which are killing the - program. It is described in the linked-to page. -
- - -Return to the top of the page or - to the libstdc++ homepage. -
- - - - --See license.html for copying conditions. -Comments and suggestions are welcome, and may be sent to -the libstdc++ mailing list. -
- - - -