This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python API - nested pretty printers MI implications
- From: Daniel Jacobowitz <drow at false dot org>
- To: Andrew Oakley <andrew at ado dot is-a-geek dot net>
- Cc: gdb at sourceware dot org
- Date: Sun, 14 Aug 2011 18:18:30 -0400
- Subject: Re: Python API - nested pretty printers MI implications
- References: <20110814171023.19db4f49@ado-gentoo>
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!
> 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...
> 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.
--
Thanks,
Daniel