This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Patch: implement new dynamic varobj spec
- From: Tom Tromey <tromey at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 14 Sep 2009 14:03:05 -0600
- Subject: Re: Patch: implement new dynamic varobj spec
- References: <m3r5uejz4y.fsf@fleche.redhat.com> <83y6okzfl6.fsf@gnu.org>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
Tom> +Note that if Python support has not been compiled into @value{GDBN},
Tom> +this command will still succeed.
Eli> Suggest to add "(and do nothing)" to the end of the sentence
Eli> Btw, does this silent failure have good reasons?
There just didn't seem to be much value in issuing an error.
Tom> +This operation returns attributes of the newly-created varobj. These
Tom> +include, but are not limited to:
Eli> Why don't we have an exhaustive list here?
We may add attributes later.
Tom> +@item thread-id
Tom> +If a fixed variable object is bound to a specific thread, then this is
Tom> +the thread's identifier.
Eli> Is "fixed" used here as opposed to "dynamic"?
I don't know where that came from, I removed the "fixed".
Tom> +For a dynamic varobj, this value cannot reliably be used to form an
Tom> +expression. Also, a dynamic varobj will not report the access
Tom> +qualifying pseudo-children, regardless of the language.
Eli> Do we want to give the reader some hints as to how to achieve these
Eli> with dynamic varobjs?
There is no way to do these.
Tom