GDB step (in) isn't working for std::string

Question

Using GDB (CGDB) I can step into the code of C++ standard library containers such as std::vector or std::set , but not std::string . Does anyone know why? Can I somehow enable this? I am using Ubuntu 20.04.

#include <vector>
#include <set>
#include <string>

int main(int argc, char *argv[])
{
  std::vector<double> v;
  std::set<double> s;
  std::string str;
  return 0;
}

For example, after compiling the code above with g++ -g debug.cpp , I can step into the std::vector and std::set constructors (and base class constructors etc.), but not std::string .

Answer 1

Does anyone know why?

This is happening because std::vector and std::set are templated classes which are (necessarily) defined in header files, while std::string is not.

In order to avoid repeatedly compiling std::string methods in each .cpp file, these methods are defined in libstdc++ .

You can't step into them because you haven't installed libstdc++ debuging symbols package.

Can I somehow enable this?

Yes: install the debug info for libstdc++ , appropriate for your system. On my (Debian) system that's libstdc++6-dbgsym , and with it installed, you would see something like:

Breakpoint 1, main (argc=1, argv=0x7fffffffdc28) at t.cc:9
9        std::string str;
(gdb) s
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffffdaa0) at /build/gcc-10-R1sACw/gcc-10-10-20200324/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:433
433     /build/gcc-10-R1sACw/gcc-10-10-20200324/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h: No such file or directory.

Now, this is still pretty bad, because it refers to temporary build directory which doesn't exist anywhere, except on the maintainer system.

But you can use GDB dir command to point GDB to appropriate source directory (which you can obtain by installing source package for libstdc++ ).

PS You could also avoid this problem by building your own g++ version, but that may be more trouble than it's worth.

PPS It's very rare that you actually need to step into std::string (or any other std:: methods. Most of the time you can just assume that they work correctly, and/or look at the source to see how they are implemented.