Re: Variable objects and STL containers

Nick Roberts
2008-02-11T20:28:24Z

> > Will the Python integration be self contained or does it require separate
> > libraries?
>
> To use Python you'd need a Python interpreter library.
>
> > Will it restrict the number of platforms that GDB builds on?
>
> If you don't have Python, Python support won't be compiled.

So if you don't have Python, your patch for variable objects for STL containers
will not work.

> > In any case, there seem to be two projects here: Python integration and
> > the display of STL containers using variable objects. It's not clear to
> > me that the former is necessary for the latter.
>
> Well, I have patches in the works for both.

Can they be presented separately?

> > Below is just a quick sketch of the thoughts I have, which may or may not
> > be sensible.
> >
> > In the case of vectors, var->num_children would be computed from n =
> > v._M_impl._M_finish - v._M_impl._M_start and the children would be created
> > from *(v._M_impl._M_start+1), *(v._M_impl._M_start+2),
> > ...*(v._M_impl._M_start+n).
>
> I think it should be: *(v._M_impl._M_start+0),...,*(v._M_impl._M_start+n-1).

Yes.

> > I guess a special variable object would need to be created for n and when
> > it was reported as changed bt -var-update, new/old variable objects could
> > accordingly be created/deleted.
>
> I don't see why we need a separate variable object. If the number of
> children of a variable object changes, then -var-update can include that
> variable object in the result (and tell the new number of children).

I just think it might mean that the output of -var-update need not change.
If n changes the frontend can create/delete the extra/old variable objects.

> Now the question is whether the children that are no longer present should
> be deleted, and whether new children should be auto-created.
>
> It is probably better to auto-delete varobjs corresponding to the children
> that are gone. Then, -var-update output will list those children, with
> 'in_scope' attribute mentioning varobj is gone. Frontend is most likely to
> want those varobjs to be gone, and doing this automatically saves frontend
> complexity.

I think it may involve a bigger change to the MI output.

> Note that even if frontend wants to hold to the value of now-deleted child,
> for some reason, it must do it explicitly. Suppose that we don't auto-delete
> children, and the number of children first decreases by one and then
> increases by one. The varobj that corresponds to the last original child
> now is not accessible in any way. It's not accessible via children list of
> it's parent. It's not accessible by the name -- as the name got reused when
> new child is added. So, we cannot even get the value of that varobj.

I don't think we should worry about keeping the value of STL members that
have been deleted - at least for now.

> I think that likewise, -var-update should create varobjs for new children,
> and return them -- we probably need a new attribute to indicate that a
> varobj was just created. This might sound like breaking frontends not
> prepared to see new varobjs in -var-update output. However, this dynamic
> child behaviour will happen only as result of explicit request from
> frontend.

AFAIK, if three new members are created and two deleted, all the executable
needs to know is that there is one new member. That's why I think it may be
simple to just have a special variable object that tells the front end when the
number of members changes.

> It's natural to give frontend a choice between 'raw' representation and
> 'pretty' representation, and for compatibility, it's best to default to
> 'raw'. And if frontend asks gdb to use pretty representation for a varobj,
> or all varobj of given type, we can expect the frontend to property handle
> auto-created varobjs.

An option for this sounds like a good idea.

> Does this make sense?

Overall, it does. I think it would be a good idea to allow room for possible
changes in implementation detail.

--
Nick http://www.inet.net.nz/~nickrob