Vladimir Prus


vladimirprus.com

Saturday, June 06, 2009

STL Visualization

As of today, KDevelop can nicely display std::vector. I'll probably omit the obvious snapshot, and will point to a mailing list post with instructions for trying it. Instead, I'll tell the story of this feature.

For its entire history, GDB did not have any official way to display types from the C++ Standard Library in a sensible way. Several third-party scripts appeared, written in GDB's internal scripting language. However, they were fairly limited. You had to explicitly run those scripts, and all you got was text output without structure, making robust IDE integration impossible. Also, GDB's scripting language is itself unpleasant, and does not even have access to internal data structures and functions. It was clear that we need a way to write pretty-printers using real scripting language, with full access to GDB data structures, and proper integration with frontend interface.

The first prototype of Python-based pretty printing was written by myself during free hack slot at a CodeSourcery company meeting. It took maybe 4 hours, if not less, and could display std::string as string automatically. Some 4 hours more lead to the first public prototype. This version could automatically display std::vector as "[1,2]". The second prototype could finally display elements of std::vector as children, like one would expect in a variables tree of a frontend, and even report when new elements are added to the vector. However, this version took a couple of days of work, exposed a mere 4 functions from GDB to Python, and was a mess internally. It was clearly already outside the "quick hack" range.

Those prototypes would never turn into anything, were it not for Tom Tromey and Thiago Bauermann, who started a project to add complete Python scripting to GDB. This is much more ambitious than just pretty-printing. In particular, it includes defining new commands in Python, with full access to GDB internals. You can read more details in a post series by Tom.

Pretty-printing became a part of that large effort, and was greatly improved. One of the most notable change was incremental fetch of children. According to the C++ standard, an object does not exist until its constructor has exited. However, gcc debug info just lists all local variables in a block. A naive pretty-printer, when invoked on such a variable, would likely go into uncharted part of memory trying to fetch all children, and never return. To fix this, the Python pretty-printers were designed to use incremental fetch, using Python iterators, and GDB MI interface was also adjusted to be more incremental (yes, it's a trend). Beyond that, we've spend at least 3 weeks iterating on finer details. The GDB patch was finally checked in on Sep 15, and KDevelop4 patch shortly after.

This is still early implementation, and might have bugs, but now it's out for everybody to try.

6 comments:

Blackpaw said...

Very impressive, I look fwd to giving it a spin.

Anonymous said...

Proofread carefully to check if you any words out.

Elv13 said...

Finally, it was the main reason why I never debug under Linux and "support" doing it in VisualStudio. I hope you add this to Qt-stl reimpletation too.

Mirek said...

Very good work.
But, how is this related
with the gdb branch archer :
http://sourceware.org/gdb/wiki/ProjectArcher
This gdb branch comes whith fedora11 distrubution:

http://fedoraproject.org/wiki/Features/Archer

Vladimir Prus said...

Mirek,

the pretty-printing GDB work ended up being the part of Archer. Archer aims to solve quite a number of issues affecting GDB use on C++ projects.

Rustam said...

Hi Volodya.

I saw You message on a boost developers page about compiling the boost with libCstd on SUN.

Do You know about if the patches for SUN's libCstr were added to boost source codes?

Could You please write me back: treumer <at} gmail.com?

Beat regards,
Rustam