gdb lldb - Better variable exploring when debugging C++ code with Eclipse/CDT

how url (6)

I would like to expand on the Windows 7 response because some key steps are left out:

This is for MinGW users with Eclipse CDT

0) If you don't have python GDB, open a shell/command and use MinGW-get.exe to 'install' Python-enabled GDB e.g.

   MinGw-get.exe install gdb-python

1a) Get Python 2.7.x from and install

1b) Make sure PYTHONPATH and PYTHONHOME are set in your environment:

 PYTHONPATH should be C:\Python27\Lib   (or similar)
 PYTHONHOME should be C:\Python27

1c) Add PYTHONHOME to your PATH


2a) Open a text enter, enter the following statements. Notice the 3rd line is pointing to where the python scripts are located. See notes below about this!

import sys
sys.path.insert(0, 'C:/MinGW/share/gcc-4.6.1/python')         
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)

2b) Save as '.gdbinit' NOTE: Windows explorer will not let you name a file that starts with with a period from explorer. Most text edits (including Notepad) will let you. GDB init files are like 'scripts' of GDB commands that GBD will execute upon loading.

2c) The '.gdbinit' file needs to be in the working directory of GDB (most likely this is your projects root directory but your IDE can tell you.

3) Open your Eclipse (or other IDE) Preferences dialog. Go to the C++ Debugger sub-menu.

4) Configure Eclipse to use C:\MinGW\bin\gdb-python27.exe as the debugger and your .gdbinit as the config file.

5a) Re-create all your debug launch configurations (delete the old one and create a new one from scratch).


5b) Edit each debug configuration and point it to the new gdb-python.exe AND point it to the.

If you run into issues:

--Don't forget to change the location to the python directory in the above python code! This directory is created by MinGW, so don't go looking to download the pretty printers, MinGW did it for you in step zero. Just goto your MinGW install director, the share folder, the GCC folder (has version number) and you will find python folder. This location is what should be in python script loaded by GDB.

--Also, the .gdbinit is a PITA, make sure its named correctly and in the working folder of GDB which isn't necessarily where gdb-python.exe is located! Look at your GDB output when loading GDB to see if a) 'python-enabled' appears during load and that the statements in the .gdbinit are appearing.

--Finally, I had alot of issues with the system variables. If python gives you 'ImportError' then most likely you have not set PYTHONPATH or PYTHONHOME.

--The directory with 'gdb-python27' (e.g. C:\MinGW\bin') should also be on your path and if it is, it makes setting up eclipse a bit nicer because you don't need to put in absolute paths. But still, sometimes the .gbdinit needs an absoulte path. if it works you'll see output from gbd (console->gdb traces) like this on startup of debugger:

835,059 4^done
835,059 (gdb) 
835,059 5-enable-pretty-printing
835,069 5^done
835,129 12^done
835,129 (gdb) 
835,129 13source C:\MinGW\bin\.gdbinit
835,139 &"source C:\\MinGW\\bin\\.gdbinit\n"
835,142 13^done
835,142 (gdb) 

Using Eclipse and CDT to debug C++ code the variable windows is cumbersome and not very informative for types defined in the standard template library or in boost (e.g. shared_ptr).

Just an example how this may look like for an std::vector:

bar {...}   
    std::_Vector_base<TSample<MyTraits>, std::allocator<TSample<MyTraits> > >   
        _M_impl {...}   
            std::allocator<TSample<MyTraits> >  {...}   
            _M_start    0x00007ffff7fb5010  
            _M_finish   0x00007ffff7fd4410  
            _M_end_of_storage   0x00007ffff7fd5010  

Even if this information about the internals of those types may be useful, in almost any cases I would expect a clearer presentation here, i.e. a list of values for the std::vector. Are there any tools, plugins or other modifications around which can do this?


The following solutions does not work for linux. I am using ubuntu 14.04, eclipse, g++, gdb.

I cant find a package gdb-python and linux does not use mingw

In debug view in variables list expand vector:

"vector_name" -> std::_Vector_base<"datatype"> -> _M_impl

then right click on _M_start and select "Display as array...", type its length and then click OK. Now you can expand each item of your vector.

If you have gdb support for CDT (see, for example, GDB in Eclipse), you could try this: De-referencing STL containers

Long ago I also stumbled upon your same problem. It was a pain to check the STL containers. Then I found that link and added to my .gdbinit file some of those definitions. Life was easier after that.

NOTE: My gdb version is 7.1 and adding those definitions work fine. I don't know if in newer versions of gdb they are already included.

You need a version of GDB capable of using python to pretty print structures. I know at least on windows using mingw that this is not provided in the default install.

Pretty Printers are python modules which tell gdb how to display a given structure. You can write your own, but there are already printers for STL available for download.

To Get Pretty Printers working on Windows (instructions should be similiar for other OS's):



  • Open a command Shell and type:

    mingw-get install gdb-python
  • When its finished cd to a local directory and install the printers by typing:

    svn co svn://
  • Open the .gdbinit (create it in a text editor if need be) and type the following replaceing "C:/directory" with the folder that you checked the printers into.

    import sys
    sys.path.insert(0, 'C:/directory')
    from libstdcxx.v6.printers import register_libstdcxx_printers
    register_libstdcxx_printers (None)

Eclipse Setup

  • Go To Windows > Preferences > C/C++ > Debug > GDB
  • Where it Says GDB Debugger put the path to the python enabled GDB it will most likely be in the mingw /bin folder with a name like gdb-python27.exe
  • Where it says GDB Command File put the path to the .gdb init file you made earlier.

That's it, debug like normal, the stl structures should be much easier to read.

Well, gdb don't natively support STL containers. You can't say this is incorrect, since it will expose the inner workings of the STL objects, but most of the time it is not what we want, right?

If you're using gdb 7.0 you can take advantage of the pretty printers. This website has a pretty simple tutorial on how to set them. I copied below the part that interests you:

  1. Check-out the latest Python libstdc++ printers to a place on your machine. In a local directory, do:

        svn co svn://
  2. Add the following to your ~/.gdbinit. The path needs to match where the python module above was checked-out. So if checked out to: /home/maude/gdb_printers/, the path would be as written in the example:

        import sys
        sys.path.insert(0, '/home/maude/gdb_printers/python')
        from libstdcxx.v6.printers import register_libstdcxx_printers
        register_libstdcxx_printers (None)

The path should be the only element that needs to be adjusted in the example above. Once loaded, STL classes that the printers support should printed in a more human-readable format. To print the classes in the old style, use the /r (raw) switch in the print command (i.e., print /r foo). This will print the classes as if the Python pretty-printers were not loaded.

Since you're using eclipse cdt, don't forget to point your debug configuration to your .gdbinit file. When creating a new Debug Configuration, go to the Debugger tab and put the path to the .gdbinit file in the "GDB command file" field.

I hope that helps!

I solved it this way on a Mac. I used Homebrew to install the latest version of gcc/g++. They land in /usr/local/bin with includes in /usr/local/include.

I CD'd into /usr/local/bin and made a symlink from [email protected] to just g++ cause that @ bit is annoying.

Then I went to MyProject -> Properties -> C/C++ Build -> Settings -> GCC C++ Compiler and changed the command from "g++" to "/usr/local/bin/g++". If you decide not to make the symbolic link, you can be more specific.

Do the same thing for the linker.

Apply and Apply and Close. Let it rebuild the index. For a while, it showed a daunting number of errors, but I think that was while building indexes. While I was figuring out the errors, they all disappeared without further action.

I think without verifying that you could also go into Eclipse -> Properties -> C/C++ -> Core Build Toolchains and edit those with different paths, but I'm not sure what that will do.

c++ eclipse gdb eclipse-cdt