How to dump STL container data in gdb?

Question

I am not able to dump STL unordered map container values in gdb. variable type is std::unordered_map<> var;

my gdb version - 7.7.1 Gdb configuration:

 configure --host=x86_64-linux-gnu --target=x86_64-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --with-lzma
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)
             --with-system-gdbinit=/etc/gdb/gdbinit
             --with-zlib
             --without-babeltrace

g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

what is right way to print STL container values n gdb?

gdb output of map container:

p var

$3 = {<std::__allow_copy_cons<true>> = {<No data fields>},                                                                                                                          [13/5219]
  _M_h = {<std::__detail::_Hashtable_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<ch
ar> > const, Metrics_s*>, std::__detail::_Select1st, std::equal_to<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::hash<std::basic_string<char, std::ch
ar_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Hashtable_traits<true, false, true> >> = {<std::__detail::
_Hash_code_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Metric
s_s*>, std::__detail::_Select1st, std::hash<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >

Answer 1

Try checking out this: https://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python/

And adding these line's to your: ~/.gdbinit

python
import sys
sys.path.insert(0, '<Path to SVN Checkout Directory>')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end

If it doesn't work you can checkout an older release from SVN nearer to the version of GDB you are using.

Note: Assuming your GDB has python back-end enabled.

Update: In-case you are using the gdb package from Ubuntu packages you can try to install following package to add support for "STL pretty-printing": libstdc++6-4.8-dbg.
With this update gdb should automatically support pretty printing for STL container.

Answer 2

Your gdb --configuration output is missing --with-python clause, so I assume your gdb really cannot use python extensions. According to this SO answer gdb pretty printing is not working it seems to be necessary for pretty-print to work.

My ubuntu 14.04 in docker comes with pretty-print working as well as gdb is configured using --with-python. It seems, your gdb installation is somehow customized. You can either recompile the gdb from sources with correct options or try to clean reinstall gdb from your distribution packages.

Answer 3

1) Python is not required by older versions of gdb to print STL objects. The error with python has something to do with your configs.

gdbinit is not a gdb config

2) There is a solution that will work regardless: uninstall and reinstall old ones(look for stl pretty print packages on your distribution) gdb dbg packages also check your user's .bashrc (you may do something with gdb there which you don't want), purge it, restart terminal and it will work.

Note there are recent versions of gdb that need python of only particular version and flavor and they have quite a few bugs and some Linux distributions include them as default and it's their problem, gdb is not a one thing - it's a tree of things. Make sure you get the right one, in mine opinion it should nothing to do with python.

Here is the link describing on when that bad idea was introduced in gdb and why people seemed to like it https://bbs.archlinux.org/viewtopic.php?id=87299