Re: semantics of dynamic varobj

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