GDB capabilities for exploring STL classes - Linux

This is a discussion on GDB capabilities for exploring STL classes - Linux ; Hi * I often use gdb to debug my programs under linux. But I can't obtain all information that I want to know about some program's data. For example for STL stream classes gdb emits such message " type>". Or ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: GDB capabilities for exploring STL classes

  1. GDB capabilities for exploring STL classes

    Hi *

    I often use gdb to debug my programs under linux. But I can't obtain
    all information that I want to know about some program's data. For
    example for STL stream classes gdb emits such message " type>". Or how can see the contents of vector or list classes without
    some "magic" and annoying enormous type conversion statements? How can
    I get information about all internals of stl classes? Should I somehow
    recompile libstdc++ with debug flags or recompile my progs with some
    specific debug flags? Or gdb can't do such things at all?

    Thanks in advance.


  2. Re: GDB capabilities for exploring STL classes

    "Dmitry Chumack" writes:

    > I often use gdb to debug my programs under linux. But I can't obtain
    > all information that I want to know about some program's data. For
    > example for STL stream classes gdb emits such message " > type>".


    You'll need to build g++ from source, or obtain libstdc++-debug
    package for your distribution.

    > Or how can see the contents of vector or list classes without
    > some "magic" and annoying enormous type conversion statements?


    This may help:
    http://www.stanford.edu/~afn/gdb_stl_utils/

    > How can
    > I get information about all internals of stl classes?


    Most of the time you *don't* want all internals.

    When you do, just print the object of the type you are interested
    in. With the exception of streams, gdb will usually print more than
    you want.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: GDB capabilities for exploring STL classes


    Paul Pluzhnikov wrote:

    > You'll need to build g++ from source, or obtain libstdc++-debug
    > package for your distribution.


    I use Slackware 11.0. How can build gcc with debug libstd++ and use it
    in common with native system's gcc? Or where I can get debug version of
    libstdc++ for my distribution?


  4. Re: GDB capabilities for exploring STL classes

    Hello,

    Dmitry Chumack wrote:

    >
    > Paul Pluzhnikov wrote:
    >
    >> You'll need to build g++ from source, or obtain libstdc++-debug
    >> package for your distribution.

    >
    > I use Slackware 11.0. How can build gcc with debug libstd++ and use it
    > in common with native system's gcc? Or where I can get debug version
    > of libstdc++ for my distribution?


    For many purposes you won't need a debug release, because it won't
    improve debugging too much. Most of e.g. the STL code is in the header
    files, and is compiled with your source code. You will most probably
    not need debugging in the code compiled into the libstdc++.so binary.

    The problem is that for optimization some techniques have been applied
    making using a debugger to display data very hard, e.g. at some places
    casts are used to mask types, and base classes with narrow interfaces
    are used. You will have to apply the equivalent of printf debugging to
    be able to display data structures nicely. There is no switch to change
    behaviour of libstdc++ in this respect, i.e. making the job easier for
    gdb.

    There has been a library of GDB function by Ulrich Eckhardt,
    libgdb-stdc++, which used to work nicely up to the g++-3.3 series.
    Later this stopped working because of some optimizations in libstdc++ I
    mentioned above. It is probably not possible to implement an
    alternative for later g++ releases with the current abilities of gdb.
    This would perhaps need the ability to extract template parameters from
    fully qualified template types and constructing them to other type
    names, which gdb does not offer currently, AFAIK. I guess this would be
    pretty hairy to implement.

    Aside from those problems, the following page tells what you can expect
    from debugging support, basicalling code instrumentation with
    additional checks, not making the job of gdb easier, i.e. allowing gdb
    to print the contents of a container.

    http://gcc.gnu.org/onlinedocs/libstdc++/debug.html

    Bernd Strieder


+ Reply to Thread