Re: Patch: implement new dynamic varobj spec

[Tom Tromey <tromey@redhat.com>]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> Dynamic variable objects seem to behave differently to the current
Nick> ones:

Yeah.

Nick> 1) Children are reported (and presumably created) in var-update
Nick> even though only a root variable object may have been created,
Nick> i.e., not -var-list-children has been invoked.

It should only report children if you previously requested them.

It may create a child at any time by asking the Python printer; but a
child created this way won't be reported.  This is needed to properly
report has_more.

Nick> 2) -var-update seems to list changes to children of dynamic
Nick> objects in reverse numerical order.

Oh, odd.  But not a bug, really, as the order is not specified.

Nick> Does -var-set-update-range only work for dynamic variable objects
Nick> - the documentation doesn't say but I couldn't get it to work with
Nick> current ones.

Yeah, I think it ought to work.  I'm not sure how useful it is, though.

Nick>  With dynamic variable objects I could restrict the
Nick> range but it didn't seem to match up (from seem to be ignored).

I will look into this.

Nick> The new FROM TO arguments for -var-list-children work with current
Nick> variable objects but it seems that GDB just restricts what it
Nick> prints but stores the whole vector which doesn't seem to save
Nick> memory.  Would it not be better to create children in the range
Nick> specified since the array might be large and the front end only
Nick> needs the values it displays.

We designed a very simple Python API that does not support random
access.  The reason for this is that a simple API is easier for users.
Naturally, this is an arguable decision.

The real intent for limiting the range is not to save memory but to
avoid problems printing uninitialized containers.  I think a front end
ought to always restrict the range when fetching the children of a
dynamic varobj.  I suppose I will update the documentation to say this.

For dynamic varobjs, we do save a bit of memory because the TO argument
limits how many children we compute.

Nick> Likewise with -var-set-update-range: does GDB track all changes
Nick> and just report a restricted set, or restrict what it tracks?

It always starts over at 0, and then filters on the low side after
computing differences.  On the high side, TO (really TO+1, due to
has_more computation) limits how many children we fetch.

Nick> I have a few thoughts about the documentation:

Thanks, I'll fix these.

Nick> The field `displayhint' seems very useful with -var-create but
Nick> does it serve any purpose when output with -var-update?

It could change -- bizarre but in theory possible.

Nick> The field `has_more' seems to be overloaded depending on whether
Nick> its output from -var-create, -var-list-children or -var-update.

How do you mean?  I think it means pretty much the same thing in all
cases: it is true if the object has children beyond what you've
requested.

Nick> Existing documentation uses @var for field names, while new uses @samp.

Yeah.  @var seems clearly wrong there.
I will change the new code though.

Nick> I find varobj.c hard to read 

Yes, me too.

Tom