Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Pretty printing in gdb7

>>>>> "Terry" == Terry Parker <tparker@xxxxxxxxxx> writes:

Terry> I've been playing with the DSF-GDB framework (rc3) and a recent build
Terry> of gdb7.  Together they make a compelling story for debugging C++
Terry> binaries with Eclipse.

Cool.

Terry> I'm seeing some problems with the Python pretty printing support.  The
Terry> pretty printing works well for non-MI commands, but some of the MI
Terry> commands are reporting the actual implementation structure while
Terry> others report the underlying data.  A quick summary:

Terry> 2) std::set and std:map objects don't expose their elements.  The
Terry> "var-list-children" MI command on these objects always returns a value
Terry> of "0", making it appear that the set/map is empty.

Make sure you have the most recent pretty-printers.
I think we had some bugs involving set and map at one point.

If it still fails, please file a bug report in gdb or gcc bugzilla.
For best results, CC me directly.  I will look at these fairly
quickly; we want libstdc++ printing to be bulletproof.

Terry> 3) std::vectors cause an internal gdb assertion and exit.
Terry> "var-list-children" returns the correct number of elements in the
Terry> vector, but "var-info-path-expression var.[N]" commands, which should
Terry> return the vector's parameterized type, instead return the vector's
Terry> implementation structure. So "var-info-path-expression var.[0]"
Terry> returns "std:_Vector_base..." and "var-info-path-expression var.[1]"
Terry> asserts because vector only contains a single child member.

I think this is an oversight in the pretty-printing code, and we may
need some improvements here :-(

I will look into it a bit more.

Tom


Back to the top