This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: STL containers
On Jul 15, 2004, at 12:05 PM, Przemyslaw Sliwa wrote:
Is it possible to display a content of the STL containers by gdb?
In the Apple integrated development environment (Xcode), we handled
this in two ways. One, we added a "print for debugger" class to many
of the standard Objective-C classes, and two, our UI has a "custom data
formatters" feature.
For objects supporting the "print for debugger" method, we have a
"print-object" or "po" command in gdb which invokes taht method on a
given object. The print for debugger methods prints the object's
contents to stdout in some human-meaningful way.
For the custom data formatters, our debugger UI comes with a bunch of
pre-canned formatters. For a simple structure, like a structure that
represents the height and width of a rectangle (with structure data
member names "height" and "width"), you'd write width=%width%,
height=%height%, and in the UI the variable summary field looks like
"width=100, height=150". gdb is just grabbing the children of a varobj
- very fast.
The custom data formatters also allow you to make inferior function
calls to extract information from objects that don't have a simple
representation. We provide these custom data formatters for the main
classes in our graphics frameworks. We don't provide them for STL yet,
but the point of this feature was that it'll be easy to add them for
STL classes in the future as well. (and users can easily write their
own custom data formatters for STL or their own classes).
Unfortunately I don't think either of these approaches will help you
much. The "print for debugger" method requires collaboration with the
library provider. The "custom data formatters" method requires a lot
of work in a debugger UI sitting above gdb. I don't think it makes
much sense to try to put these kinds of facilities directly inside gdb,
but that's just MHO.
(in case anyone is wondering, yes, having lots of custom data
formatters doing inferior function calls does slow down stepping speed.
They are easily disabled in the UI and we encourage people to do so
when they've got too many locals being formatted at each step.)
J