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 00:18:30 ext Daniel Jacobowitz wrote:
> On Sun, Aug 14, 2011 at 12:10 PM, Andrew Oakley
> <andrew@ado.is-a-geek.net> wrote:
> > I've got a patch to allow the Python pretty printer children iterators
> > to return more pretty printers so they can create "phony groups" a bit
> > like this:
>
> Yay!
That would be really nice to have indeed.
> > As far as I can tell I need to create "fake" varobj structures with no
> > underlying value or type (because I don't have one). This appears to
> > already happen and is tested for with CPLUS_FAKE_CHILD, but I'm not
> > quite sure what that is for. Does this seem like a reasonable thing to
> > do (after searching around for CPLUS_FAKE_CHILD)?
>
> It does seem like a reasonable idea, but watch out for
> CPLUS_FAKE_CHILD; it may not be a good model. It's used right now for
> public/protected/private groups, and no one seems to want it there -
> it might go away at some point.
>
> > My other worry is varobj invalidation and update. Am I correct in
> > thinking that updates can only happen from a "root" varobj? If so it
> > should be possible to reconstruct the "fake" varobj structures in
> > varobj_update (I don't think it will be straightforward though).
>
> My memory on this is a bit spotty. I think it may be possible to
> update non-root varobjs, but it's the common case to update the root.
> That might have been an out-of-tree patch though...
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?
[While the example might look contrived, it is a situation that naturally
arises when using "phony levels", in various ways.]
The only working "solution" for this kind of problem I am aware of is to
"manually" force a full re-evaluation of all top level items, i.e. not to
rely on varobj's update mechanism at all.
> > Am I correct in assuming you would want MI to work before accepting
> > patches?
>
> Even if it's not a requirement, I strongly encourage it.
From a gdb/python (and previously varobj...;-)) user's point of view it
would be nice if caring for MI's varobj machinery (I really only mean
the varobjs, not MI in general) would not impact progress on the "pure"
python side much.
Andre'