Pretty printing in gdb7

[Terry Parker-3]

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

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

1) std::string objects work great.  No more digging down 3-4 levels of
basic_string structure to get the char* (which sometimes only shows
the first character, so you need to copy the address to a memory view)

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

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

Is anyone having any success with gdb7's new pretty printing under the
DSF-GDB framework?  Any insight on whether what I am seeing is
requires a gdb fix or can be fixed in the Python scripts for pretty
printing?  Or would it be easier to tackle this by modifying DSF-GDB
itself?  Any pointers are welcome.

Thanks,
Terry Parker
Google, Inc.
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Marc Khouzam]

 

> -----Original Message-----
> From: cdt-dev-bounces@...
> [mailto:cdt-dev-bounces@...] On Behalf Of Terry Parker
> Sent: June-05-09 2:05 PM
> To: CDT General developers list.
> Subject: [cdt-dev] Pretty printing in gdb7
>
> I've been playing with the DSF-GDB framework (rc3) and a recent build
> of gdb7.  Together they make a compelling story for debugging C++
> binaries with Eclipse.
>
> I'm seeing some problems with the Python pretty printing support.  The
> pretty printing works well for non-MI commands, but some of the MI
> commands are reporting the actual implementation structure while
> others report the underlying data.  A quick summary:
>
> 1) std::string objects work great.  No more digging down 3-4 levels of
> basic_string structure to get the char* (which sometimes only shows
> the first character, so you need to copy the address to a memory view)
>
> 2) std::set and std:map objects don't expose their elements.  The
> "var-list-children" MI command on these objects always returns a value
> of "0", making it appear that the set/map is empty.
>
> 3) std::vectors cause an internal gdb assertion and exit.
> "var-list-children" returns the correct number of elements in the
> vector, but "var-info-path-expression var.[N]" commands, which should
> return the vector's parameterized type, instead return the vector's
> implementation structure. So "var-info-path-expression var.[0]"
> returns "std:_Vector_base..." and "var-info-path-expression var.[1]"
> asserts because vector only contains a single child member.
>
> Is anyone having any success with gdb7's new pretty printing under the
> DSF-GDB framework?  Any insight on whether what I am seeing is
> requires a gdb fix or can be fixed in the Python scripts for pretty
> printing?  Or would it be easier to tackle this by modifying DSF-GDB
> itself?  Any pointers are welcome.

Hi Terry,

I personnally have not tried the new python support in GDB 7 and to
be honnest, I'm not familiar with how it should be used at all.
No effort has been put in DSF-GDB to support it, but there seems
to be some interest from different people.

Sorry I can't be more helpful, but I wanted to at least let you know
that you are in uncharted territory.

I'll try to give it a spin as soon as I have some time, but I'm afraid
that won't be for a week or two.  If you make any progress, please share
your findings.  And feel free to write a bug to track this issue.

Best regards,

Marc


>
> Thanks,
> Terry Parker
> Google, Inc.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

>>>>> "Terry" == Terry Parker <tparker@...> 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
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Terry Parker-3]

Thanks, Marc

One of the better blog articles is here: http://tromey.com/blog/?p=524

I haven't found definitive documentation yet, but it looks like the
Python interface for pretty printers contains 3 functions:
1) display_hint(), optional, can return "string", "array" or "map"
2) to_string(), which can return something like "std::vector of length
X, capacity Y"
3) children(), which returns an iterator over the collection

If the MI commands are smart about using the iterator returned by
children(), this should scale to large collections and allow the
DSF-GDB framework to remain very responsive.

--Terry

On Fri, Jun 5, 2009 at 11:14 AM, Marc Khouzam<marc.khouzam@...> wrote:

>
>
>> -----Original Message-----
>> From: cdt-dev-bounces@...
>> [mailto:cdt-dev-bounces@...] On Behalf Of Terry Parker
>> Sent: June-05-09 2:05 PM
>> To: CDT General developers list.
>> Subject: [cdt-dev] Pretty printing in gdb7
>>
>> I've been playing with the DSF-GDB framework (rc3) and a recent build
>> of gdb7.  Together they make a compelling story for debugging C++
>> binaries with Eclipse.
>>
>> I'm seeing some problems with the Python pretty printing support.  The
>> pretty printing works well for non-MI commands, but some of the MI
>> commands are reporting the actual implementation structure while
>> others report the underlying data.  A quick summary:
>>
>> 1) std::string objects work great.  No more digging down 3-4 levels of
>> basic_string structure to get the char* (which sometimes only shows
>> the first character, so you need to copy the address to a memory view)
>>
>> 2) std::set and std:map objects don't expose their elements.  The
>> "var-list-children" MI command on these objects always returns a value
>> of "0", making it appear that the set/map is empty.
>>
>> 3) std::vectors cause an internal gdb assertion and exit.
>> "var-list-children" returns the correct number of elements in the
>> vector, but "var-info-path-expression var.[N]" commands, which should
>> return the vector's parameterized type, instead return the vector's
>> implementation structure. So "var-info-path-expression var.[0]"
>> returns "std:_Vector_base..." and "var-info-path-expression var.[1]"
>> asserts because vector only contains a single child member.
>>
>> Is anyone having any success with gdb7's new pretty printing under the
>> DSF-GDB framework?  Any insight on whether what I am seeing is
>> requires a gdb fix or can be fixed in the Python scripts for pretty
>> printing?  Or would it be easier to tackle this by modifying DSF-GDB
>> itself?  Any pointers are welcome.
>
> Hi Terry,
>
> I personnally have not tried the new python support in GDB 7 and to
> be honnest, I'm not familiar with how it should be used at all.
> No effort has been put in DSF-GDB to support it, but there seems
> to be some interest from different people.
>
> Sorry I can't be more helpful, but I wanted to at least let you know
> that you are in uncharted territory.
>
> I'll try to give it a spin as soon as I have some time, but I'm afraid
> that won't be for a week or two.  If you make any progress, please share
> your findings.  And feel free to write a bug to track this issue.
>
> Best regards,
>
> Marc
>
>
>>
>> Thanks,
>> Terry Parker
>> Google, Inc.
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@...
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

>>>>> "Marc" == Marc Khouzam <marc.khouzam@...> writes:

Marc> I personnally have not tried the new python support in GDB 7 and to
Marc> be honnest, I'm not familiar with how it should be used at all.

It should mostly work automatically.  The only real difference is that
now a the number of children of a varobj can change dynamically.  This
should not be hard to accommodate.

There is also a new MI command to let the MI consumer set the
visualizer for a varobj.  However, everything will work fine even if
this command is never issued.

Tom
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Terry Parker-3]

Thanks Tom,

Where should I grab the latest pretty-printers from?
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

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

Terry> Where should I grab the latest pretty-printers from?

svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python

It may be a bit tricky to set up :(
But, if you already have a working setup, you can just copy the
printers.py file on top of the one you are already using.

Tom
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

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

Terry> I haven't found definitive documentation yet

Everything is in gdb/doc/gdb.texinfo.  There's a section under the
Python scripting documentation about writing pretty-printers, and a
section about how to set them up to be auto-loaded.  The MI section of
the manual explains the new MI additions.

If the docs are confusing, or incomplete, or unclear, please report
that too, and I will fix it.

Terry> If the MI commands are smart about using the iterator returned by
Terry> children(), this should scale to large collections and allow the
Terry> DSF-GDB framework to remain very responsive.

The initial patch series included some Mi commands so that the MI
consumer could select a subset of the children for display.  In this
case I think the MI implementation still iterated over all the
children, but it would only report a subset over the channel to the MI
consumer.  So, while not as efficient as possible, it was still better
than today.

However, we removed these commands in response to maintainer comments.
The issue was that they were not used in the wild.  I think we could
resurrect these if some MI consumer implemented experimental support
for them and proved them to be a useful approach.

Tom
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Terry Parker-3]

Tom,

Thanks for the details.  Doug Evans here at Google made the gdb7
binary I'm using, so I'm cloning your archer source so I can look at
the document you mentioned and poke at the code a bit.

I did have the latest pretty-printers, so I am seeing the issue of the
"var-list-children" MI command always returning 0 with that.  Here is
the gdb/mi transcript that the DSF/GDB framework is having for at
std:set<int> foo variable with 2 elements in it:

426,114 49-var-create --thread 1 --frame 0 - * foo
426,114 49^done,name="var7",numchild="2",value="std::set with 2
elements",type="std::set<int, std::l\
ess<int>, std::allocator<int> >",thread-id="1"
426,116 (gdb)
426,116 50-var-list-children var7
426,117 50^done,numchild="0"

--Terry

On Fri, Jun 5, 2009 at 12:18 PM, Tom Tromey<tromey@...> wrote:

>>>>>> "Terry" == Terry Parker <tparker@...> writes:
>
> Terry> I haven't found definitive documentation yet
>
> Everything is in gdb/doc/gdb.texinfo.  There's a section under the
> Python scripting documentation about writing pretty-printers, and a
> section about how to set them up to be auto-loaded.  The MI section of
> the manual explains the new MI additions.
>
> If the docs are confusing, or incomplete, or unclear, please report
> that too, and I will fix it.
>
> Terry> If the MI commands are smart about using the iterator returned by
> Terry> children(), this should scale to large collections and allow the
> Terry> DSF-GDB framework to remain very responsive.
>
> The initial patch series included some Mi commands so that the MI
> consumer could select a subset of the children for display.  In this
> case I think the MI implementation still iterated over all the
> children, but it would only report a subset over the channel to the MI
> consumer.  So, while not as efficient as possible, it was still better
> than today.
>
> However, we removed these commands in response to maintainer comments.
> The issue was that they were not used in the wild.  I think we could
> resurrect these if some MI consumer implemented experimental support
> for them and proved them to be a useful approach.
>
> Tom
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Marc Khouzam]

Hi,

I think this thread on pretty-printing for CDT fizzled out.
Sorry about that.  But now that GDB 7.0 is out, it may be time
to push it a bit.

If anyone made some progress they can share, the issue is being
tracked by bug 275238.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=275238

Based on the MI documentation, I get the feeling there is work
to do for DSF-GDB to support new MI fields and new behavior, before
we can support pretty-printing nicely.

Thanks

Marc

> -----Original Message-----
> From: cdt-dev-bounces@...
> [mailto:cdt-dev-bounces@...] On Behalf Of Terry Parker
> Sent: Friday, June 05, 2009 4:44 PM
> To: Tom Tromey; CDT General developers list.
> Subject: Re: [cdt-dev] Pretty printing in gdb7
>
> Tom,
>
> Thanks for the details.  Doug Evans here at Google made the gdb7
> binary I'm using, so I'm cloning your archer source so I can look at
> the document you mentioned and poke at the code a bit.
>
> I did have the latest pretty-printers, so I am seeing the issue of the
> "var-list-children" MI command always returning 0 with that.  Here is
> the gdb/mi transcript that the DSF/GDB framework is having for at
> std:set<int> foo variable with 2 elements in it:
>
> 426,114 49-var-create --thread 1 --frame 0 - * foo
> 426,114 49^done,name="var7",numchild="2",value="std::set with 2
> elements",type="std::set<int, std::l\
> ess<int>, std::allocator<int> >",thread-id="1"
> 426,116 (gdb)
> 426,116 50-var-list-children var7
> 426,117 50^done,numchild="0"
>
> --Terry
>
> On Fri, Jun 5, 2009 at 12:18 PM, Tom Tromey<tromey@...> wrote:
> >>>>>> "Terry" == Terry Parker <tparker@...> writes:
> >
> > Terry> I haven't found definitive documentation yet
> >
> > Everything is in gdb/doc/gdb.texinfo.  There's a section under the
> > Python scripting documentation about writing pretty-printers, and a
> > section about how to set them up to be auto-loaded.  The MI
> section of
> > the manual explains the new MI additions.
> >
> > If the docs are confusing, or incomplete, or unclear, please report
> > that too, and I will fix it.
> >
> > Terry> If the MI commands are smart about using the
> iterator returned by
> > Terry> children(), this should scale to large collections
> and allow the
> > Terry> DSF-GDB framework to remain very responsive.
> >
> > The initial patch series included some Mi commands so that the MI
> > consumer could select a subset of the children for display.  In this
> > case I think the MI implementation still iterated over all the
> > children, but it would only report a subset over the
> channel to the MI
> > consumer.  So, while not as efficient as possible, it was
> still better
> > than today.
> >
> > However, we removed these commands in response to
> maintainer comments.
> > The issue was that they were not used in the wild.  I think we could
> > resurrect these if some MI consumer implemented experimental support
> > for them and proved them to be a useful approach.
> >
> > Tom
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@...
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________

cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev