This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: semantics of dynamic varobj
- From: Tom Tromey <tromey 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 09:12:03 -0700
- Subject: Re: semantics of dynamic varobj
- Authentication-results: sourceware.org; auth=none
- References: <528F5839 dot 4050100 at codesourcery dot com>
>>>>> "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