This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: semantics of dynamic varobj
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Fri, 22 Nov 2013 13:28:24 +0000
- Subject: Re: semantics of dynamic varobj
- Authentication-results: sourceware.org; auth=none
- References: <528F5839 dot 4050100 at codesourcery dot com>
On 11/22/2013 01:12 PM, Yao Qi wrote:
> Nowadays, if a varobj's contents are provided by pretty-printer, it is
> called dynamic varobj. However, it is unclear to me what is a dynamic
> varobj? What is the "dynamic" part of dynamic varobj? the children?
>
> IIUC, the children of dynamic varobj vary. That is why returned
> attributed 'numchild' of -var-create is "not necessarily reliable", right?
Right. With a dynamic varobj, you don't know how many children are
there upfront. You only know there may be more, so you fetch more
until no more children are found. It works like an iterator.
> I ask these questions because I am adding a new kind of dynamic varobj,
> whose contents are provided by only available data. For example,
>
> struct foo
> {
> int a, b, c;
> };
> struct foo foo;
>
> foo.a and foo.c is collected in traceframe #1, while foo.b is collected
> in traceframe #2. We create a varobj foo for variable foo, if
> traceframe is #1, foo has two children (foo.a and foo.c), if traceframe
> is #2, foo has one child (foo.b). IMO, varobj foo behaves like a
> dynamic varobj.
Right. We only know whether a child is available or not when
we go and try to read it, so we can't know which children are
available upfront. The (Mentor) code for this was all
modelled/shared on/with dynamic varobjs because of this.
--
Pedro Alves