Re: [cdt-dev] Pretty printing in gdb7

[Terry Parker <tparker@xxxxxxxxxx>]

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@xxxxxxxxxxxx> wrote:
>
>
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx
>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] 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@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>