This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RCF 00/11] Visit varobj available children only in MI
- From: Yao Qi <yao at codesourcery dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: "gdb-patches at sourceware dot org ml" <gdb-patches at sourceware dot org>
- Date: Wed, 8 Jan 2014 22:25:53 +0800
- Subject: Re: [RCF 00/11] Visit varobj available children only in MI
- Authentication-results: sourceware.org; auth=none
- References: <1385258996-26047-1-git-send-email-yao at codesourcery dot com> <52CC45DD dot 3000407 at redhat dot com>
Thanks for the review, Keith.
On 01/08/2014 02:22 AM, Keith Seitz wrote:
> Why was this feature implemented this way? Specifically, if some varobj
> children are not available from trace data, isn't the decision to filter
> this information a function of the user interface? Wouldn't it have
> sufficed to add a flag to the varobj designating the child as not
> collected in the trace experiment or unavailable?
>
> I am definitely /not/ suggesting that this be re-implemented or
> re-designed. I just want to understand why this was implemented this
> way. Perhaps there is a significant speed advantage for large trace
> experiments or some other technical/legitimate reason for this
> implementation?
We don't want frontends learn much new. If they already support
pretty-print dynamic varobj, they should support available-children-only
varobj. Frontends have only to pass option "--available-children-only"
to some MI commands, and then frontends can handle the output as
correctly as it handles pretty-printer's output.
>
> That aside, one other thing I'd like to ask about: the flag
> "--available-children-only" rather strikes me like a property of the
> varobj. Not altogether unlike the display format. Is there a reason a
It (available-children-only) is a property of varobj, we add a new field
available_children_only in struct varobj_dynamic for this purpose (in
patch 07), at least, it is in the code.
> flag was chosen to implement this over, say, a (new) command like
> "-var-set-show-available-children-only" or requiring/allowing
> --available-children-only to be specified on the root varobj creation
> and "saved"/enforced for all subsequent commands on the varobj and its
> children?
Yeah, we can have a global setting to decide whether to honour
available-children-only or not, and this global setting can be
set by a new MI command.
>
> The only rationale I can think of is if a UI wanted to query gdb/mi for
> varobjs with and without this option. Is that a common use case? Is
I am not sure how common this use case is, but IMO, it is more flexible,
compared with the approach using global setting.
> there perhaps another use case which I have not considered?
>
> Finally, I didn't see any mention of documentation updates. This change
> will require both a manual update and a NEWS entry, documenting the new
> feature.
It was intended and was mentioned in the cover letter of this series.
There should be some changes during the review, which affect the doc
and NEWS.
>
> I believe Joel has committed the MI "features" series; an update to this
> might be desirable [perhaps Joel might be able to offer an opinion].
Right, we can add a new feature "mi-available-children-only" in the
reply of -list-features.
--
Yao (éå)