semantics of dynamic varobj

semantics of dynamic varobj

[Yao Qi]

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?

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.

-- 
Yao (齐尧)

Re: semantics of dynamic varobj

[Pedro Alves]

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

Re: semantics of dynamic varobj

[Tom Tromey]

>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:

Yao> I ask these questions because I am adding a new kind of dynamic
Yao> varobj, whose contents are provided by only available data.

There are maybe two things that suggest that a dynamic varobj is not the
way to go here.

One is that these aren't truly dynamic.  They are just ordinary varobjs
where some child values are unavailable.  It seems far simpler to me to
just provide an "unavailable" marker.

Second, dynamic varobjs have different semantics than ordinary ones, so
they are only enabled when the client requests them.  (And, clients may
use the "python" feature to decide this, since that's the only signal
right now that they exist.)

So, would then (1) be at least conceptually tied to Python (you could
add a new feature I suppose) and (2) have to decide what to do if the
feature is not enabled... which goes back to the idea of just treating
these as normal varobjs.

Tom

Re: semantics of dynamic varobj

[Pedro Alves]

On 11/22/2013 04:12 PM, Tom Tromey wrote:
> Second, dynamic varobjs have different semantics than ordinary ones, so
> they are only enabled when the client requests them.  (And, clients may
> use the "python" feature to decide this, since that's the only signal
> right now that they exist.)

I no longer have the full context, but these varobjs are also
only enabled when the client requests them (a new option
to -var-create, IIRC).  That is, a regular varobj will include both
unavailable and available fields, with unavailable fields listed as
"value=<unavailable>".  For those, which fields are listed
can be determined "statically", as usual, from the debug info.  While
this new varobj lists only the available fields, skipping the
unavailable ones.

I recall doing this on top of regular varobjs first, and then
realizing they behave just like dynamic varobjs, because we have no
random access to the children, and we also want to let the frontend
know the number of children changed when we move between trace
frames, with -var-update, and ynamic varobjs also support that.
In reality, I think we would be able to implement these new
varobjs as real dynamic python varobjs, with some sort of pretty
printer that skips these unavailable fields, though we might need
some fixes to the dynamic varobj code that were done as part of
this work (also useful for python varobjs, IIRC), and also I don't
think python is aware of unavailable values yet either.  That said,
I do prefer a native implementation.

(*) - Yao, as usual, the whole rationale for that should be
in CS's internal archives.

-- 
Pedro Alves

Re: semantics of dynamic varobj

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I no longer have the full context, but these varobjs are also
Pedro> only enabled when the client requests them (a new option
Pedro> to -var-create, IIRC).

Ok, thanks.

It wasn't clear from the thread whether the issues were apparent.
I'm fine with an implementation that takes them into account.

Tom

Re: semantics of dynamic varobj

[Yao Qi]

On 11/23/2013 12:37 AM, Pedro Alves wrote:
> I no longer have the full context, but these varobjs are also
> only enabled when the client requests them (a new option
> to -var-create, IIRC).  That is, a regular varobj will include both
> unavailable and available fields, with unavailable fields listed as
> "value=<unavailable>".  For those, which fields are listed
> can be determined "statically", as usual, from the debug info.  While
> this new varobj lists only the available fields, skipping the
> unavailable ones.

The option is "--available-children-only".  I'll post the patches soon.

>
> (*) - Yao, as usual, the whole rationale for that should be
> in CS's internal archives.

Yes, I've got the mail in the archives.

-- 
Yao (齐尧)