Re: [cdt-dev] Pretty printing in gdb7

[Terry Parker <tparker@xxxxxxxxxx>]

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