This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Variable objects and STL containers
On Monday 11 February 2008 00:02:23 Nick Roberts wrote:
> > > > I anticipate that -var-update will:
> > > >
> > > > 1. Create new children, and report them.
> > > > 2. Report children that are now gone, possibly deleting them.
> > >
> > > That sounds sensible. Discussion on the gcc mailing list suggested that
> > > this should all be done in GDB, i.e., in C. I will explore that
> > > possibility.
> >
> > Please note that I already have proof-of-concept Python integration,
> > together with code to use Python for -var-evaluate-expression, together
> > with not-yet-working patch to dynamically compute the list of varobj children.
> > It might be better to wait till I got the last bit done.
>
> 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.
> 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.
> 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).
> 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). 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.
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 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. 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.
Does this make sense?
- Volodya