Pretty-Printers for GDB

The Situation

I'm a firm believer that being set up with the proper tools is one of the many keys to success. This has definitely been my experience when it comes to software development. When you don't have a verbose debugger at your disposal, things seem to go quite a bit slower. I've also been repeatedly told that you just have to "deal" with imbedded application development being slower than modern development, as tools are constantly lagging behind. Although this is definitely true in some cases, I refused to believe this is the case for getting the most basic debugging capabilities readily available.

I was recently blocked by not being to inspect any basic STL types when debugging to my embedded target. The setup I was attempting to debug was the following:

• Host OS: Ubuntu Linux

• Target OS: PetaLinux, running on a Xilinx ARM CPU

• Language: C++

• IDE: Visual Studio Code

The way we debug is by running gdbserver on the target, then launching the Visual Studio Code debugger which launches the application on the target and establishes a debugging instance via connected to the gdbserer's port.

The goal here was simple (or so I thought): debug the embedded Linux application on my Host (desktop Linux) PC all within Visual Studio Code. This should work out of the box, right?

Well, I ran into one issue very quickly: all STL types & classes (such as Vector, List, Tuple, etc.) were not being shows in the Visual Studio Code debugger. And considering these data types enable some major advancements in C++ development, I planned to use many of them. When attempting to analyze a simple Vector:

I observed the following in VS Code's "watch" window:

As you can see, this info really doesn't do much for us. I was hoping to see each element in the vector, similar to how arrays are shown. I realized something must be configured wrong, so I entered into the rabbit hole of GDB Pretty Printer

GDB Pretty-Printers

All my Googling of this issue kept coming up with answers pertaining to GDB"s configurable "Pretty-Printer". Most help sites simply recommended doing something like "enable it in the CMake / Make configurations." After trying to put things into my CMake blindly, I decided to dig a bit deeper into GDB's Pretty-Printer.

It turns out that all "pretty-printer" is is a set of Python scripts that assist in displaying variables properly in GDB. In my instance, I was needing a "pretty-printer" that parsed the STL data types into a digestible output in the IDE. My specific GDB tool for PetaLinux didn't come with these STL "pretty-printers", so I had to find them. Luckily, they're very readily available. Here is a link to where you can find them in SVN: svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python. Once downloaded, you have to tell GDB on the host where to read them. This is done with the following ".gdbinit" on the host, under the currently logged in "User" directory:

python 
import sys 
sys.path.insert(0, '/***/gdb_prettyprint/python') 
from libstdcxx.v6.printers import register_libstdcxx_printers 
register_libstdcxx_printers (None) 
end 

The only change that is needed is step 3, where I put '***/gdb_prettyprint/python') Once you point that to the "Python" directory where you downloaded the STL Python scripts, every time you launch GDB it will parse this directory for "printers".

Note that I specify host. When I was originally trying to get this to work, I was convinced the target was the system that needed further configuration. After all, the code is running on the target, right? NOPE. It turns out that gdbserver is being ran on the target, but GDB is still being run on the host. Therefore the host system has to be configured with the pretty-printers.

Testing the Pretty-Printers

At this point, the host system has downloaded the pretty-printer Python scripts, and configured GDB to read them upon starting any GDB session. Next it's time to test, as this was the way I found out something's wrong during this bring-up. Luckily the GDB live terminal-view has some robust debugging for the GDB instance.

If you just run "gdb" on the host system, you should enter into the GDB environment. From there, you can execute the following command:

info pretty-print

If things are configured right, you should get the following:

global pretty-printers:
  builtin
    mpx_bound128
  libstdc++-v6
    __gnu_cxx::_Slist_iterator
    __gnu_cxx::__8::_Slist_iterator
    __gnu_cxx::__8::__normal_iterator
    __gnu_cxx::__8::slist
    __gnu_cxx::__normal_iterator
    __gnu_cxx::slist
    __gnu_debug::_Safe_iterator
...

If you're seeing this, congratulations you've successfully loaded STL pretty-printers into your GDB install! If you see something like this::

 global pretty-printers:
  builtin
    mpx_bound128

Then the pretty-printers are not recognized by GDB and something is configured wrong.

Final Result - Welcome to 21st Century of Debugging

Once I was seeing my pretty-printers, I re-ran GDB (and connected to the gdbserver), and was pleasantly greeted with this in my VS Code "watch" section:

Success! GDB is properly using the pretty-printers downloaded onto our system to interpret our STL::Vector into a human-readable format!