This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 12/12] NEWS and Doc on --available-children-only
- From: Yao Qi <yao at codesourcery dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: <gdb-patches at sourceware dot org>
- Date: Tue, 18 Feb 2014 09:59:20 +0800
- Subject: Re: [PATCH 12/12] NEWS and Doc on --available-children-only
- Authentication-results: sourceware.org; auth=none
- References: <1392367471-13527-1-git-send-email-yao at codesourcery dot com> <1392367471-13527-13-git-send-email-yao at codesourcery dot com> <83ha82c9rf dot fsf at gnu dot org> <5301D9F4 dot 5010306 at codesourcery dot com> <83zjlp93vz dot fsf at gnu dot org>
On 02/17/2014 11:04 PM, Eli Zaretskii wrote:
> No, sorry. "Children whose values are available" is not clear at all.
>
> Can you explain to me what makes the value "available", or what
> prevents it from becoming available? Then I will suggest a suitable
> wording.
OK, thanks in advance.
When GDB reads from trace frames, if the variables are collected and
saved in trace frames, GDB is able to show the valid values of these
variables. We call "values of these variables are available". OTOH,
if the variables are not collected, "their values are unavailable".
For example, in a traceframe, field a is collected but field b is not.
As a result, value of field a is available, and value of field b is
unavailable.
struct foo
{
int a; /* Collected */
int b; /* Uncollected */
};
Going to MI/varobj world, everything is structured as a tree, and each
tree node is about certain value. foo.a and foo.b are the children of
foo in MI/varobj, so foo.a is an available child of foo, but foo.b
isn't.
The concept of available and unavailable can be illustrated by GDB
accessing trace frames, but the concept itself is quite independent and
can be applied to other situations.
--
Yao (éå)