This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python API - nested pretty printers MI implications
On Monday 15 August 2011 15:33:45, André Pönitz wrote:
> On Monday 15 August 2011 15:25:48 ext Pedro Alves wrote:
> > On Monday 15 August 2011 13:36:50, André Pönitz wrote:
> >
> > > I am not sure how partial updates on MI varobjs with phony levels
> > > would work at all.
> > >
> > > Imagine a data structure containing a char m[1000000][10], and a
> > > "phony level pretty printer" that displays all the m[i] with m[i][0] == 'A'.
> > > Suppose initially that would be the items m[1] and m[10000], so we
> > > get a display like
> > >
> > > m --
> > > m[1] "A...."
> > > m[1000] "A...."
> > >
> > > Now the user steps over m[5000][0] = 'A'. Assuming there is no dummy
> > > varobj for every _potential_ child, what mechanism would trigger the
> > > varobj's update to produce the display
> > >
> > > m --
> > > m[1] "A...."
> > > m[5000] "A...."
> > > m[10000] "A...."
> > >
> > > eventually?
> >
> > AFAIK, frontends do:
> >
> > -var-update 2 *
> >
> > and that should yield (but doesn't):
> >
> > ^done,changelist=[{name="var1.m",value="",in_scope="true",type_changed="false",new_num_children="1",has_more="0",new_children=[{name="var1.m.5000",exp="5000",numchild="1",value="A....",type="foo"}]}]
> > (gdb)
> >
> > Note new_num_children. This should trigger the frontend re-fetching
> > the children of var1.m.
> >
> > I think the issue here is that dynamic varobj's code doesn't
> > handle new children appearing before existing ones. I got a
> > patch to address that though, needed for supporting varobj's
> > that hide "<unavailable>" children.
>
> Just to confirm I understood correctly: Assuming everything would work as
> planned, a good strategy for frontends is to call '-var-update ... *'. Then
> gdb would walk the whole varobj hierarchy, running pretty printers as
> appropriate, and produce a "diff" against the last reported state which is
> output as a changelist, announcing potential new children to the FE,
> which in turn could ask for that in another roundtrip.
Yes. I believe things could be extended to avoid extra roundtrips.
> If so, isn't this very similar to the "fat script" approach, where a python
> command (fed with a list of "names" of the expanded items) does all
> the tree walking by itself? That would put everything into "user space",
> let the pretty printers output additional data that's not of "general"
> (i.e. for all FEs) interest, and would make implementation of pretty
> printers with multiple phony levels straightforward?
Probably. But doesn't that mean library writters would get to write
pretty printers for each FE out there?
--
Pedro Alves