Re: Variable objects and STL containers

 > >  > I anticipate that -var-update will:
 > >  > 
 > >  > 1. Create new children, and report them.
 > >  > 2. Report children that are now gone,
possibly deleting them.
 > > 
 > > That sounds sensible.  Discussion on the gcc
mailing list suggested that
 > > this should all be done in GDB, i.e., in C.  I
will explore that
 > > possibility.
 > 
 > Please note that I already have proof-of-concept
Python integration,
 > together with code to use Python for
-var-evaluate-expression, together
 > with not-yet-working patch to dynamically compute the
list of varobj children.
 > It might be better to wait till I got the last bit
done.

Will the Python integration be self contained or does it
require separate
libraries?  Will it restrict the number of platforms that
GDB builds on?

In any case, there seem to be two projects here: Python
integration and the
display of STL containers using variable objects.  It's not
clear to me that
the former is necessary for the latter.

Below is just a quick sketch of the thoughts I have, which
may or may not be
sensible.

In the case of vectors, var->num_children would be
computed from n =
v._M_impl._M_finish - v._M_impl._M_start and the children
would be created from
*(v._M_impl._M_start+1), *(v._M_impl._M_start+2),
...*(v._M_impl._M_start+n).

I guess a special variable object would need to be created
for n and when it
was reported as changed bt -var-update, new/old variable
objects could
accordingly be created/deleted.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob


*** mi-cmd-var.c.~1.45.~	2008-01-30 21:35:45.000000000
+1300
--- mi-cmd-var.c	2008-02-11 09:42:05.000000000 +1300
*************** mi_cmd_var_list_children (char *command,
*** 361,366 ****
--- 361,369 ----
    int numchild;
    enum print_values print_values;
    int ix;
+   struct expression *expr;
+   struct value *value;
+   char* stl_member;
  
    if (argc != 1 && argc != 2)
      error (_("mi_cmd_var_list_children: Usage:
[PRINT_VALUES] NAME"));
*************** mi_cmd_var_list_children (char *command,
*** 373,379 ****
    if (var == NULL)
      error (_("Variable object not found"));
  
!   children = varobj_list_children (var);
    ui_out_field_int (uiout, "numchild",
VEC_length (varobj_p, children));
    if (argc == 2)
      print_values = mi_parse_values_option (argv[0]);
--- 376,390 ----
    if (var == NULL)
      error (_("Variable object not found"));
  
!   stl_member = xstrprintf ("%s._M_impl",
varobj_get_expression (var));
!   expr = parse_expression (stl_member);
!   if (gdb_evaluate_expression (expr, &value))
!       // TODO:  List children according to STL container.
!       children = varobj_list_stl_children (var);
!     else
!       children = varobj_list_children (var);
!   xfree (stl_member);
! 
    ui_out_field_int (uiout, "numchild",
VEC_length (varobj_p, children));
    if (argc == 2)
      print_values = mi_parse_values_option (argv[0]);

On Monday 11 February 2008 00:02:23 Nick Roberts wrote:
>  > >  > I anticipate that -var-update will:
>  > >  > 
>  > >  > 1. Create new children, and report
them.
>  > >  > 2. Report children that are now gone,
possibly deleting them.
>  > > 
>  > > That sounds sensible.  Discussion on the gcc
mailing list suggested that
>  > > this should all be done in GDB, i.e., in C. 
I will explore that
>  > > possibility.
>  > 
>  > Please note that I already have proof-of-concept
Python integration,
>  > together with code to use Python for
-var-evaluate-expression, together
>  > with not-yet-working patch to dynamically compute
the list of varobj children.
>  > It might be better to wait till I got the last
bit done.
> 
> Will the Python integration be self contained or does
it require separate
> libraries?  

To use Python you'd need a Python interpreter library.

> Will it restrict the number of platforms that GDB
builds on? 

If you don't have Python, Python support won't be compiled.

> In any case, there seem to be two projects here: Python
integration and the
> display of STL containers using variable objects.  It's
not clear to me that
> the former is necessary for the latter.

Well, I have patches in the works for both.

> Below is just a quick sketch of the thoughts I have,
which may or may not be
> sensible.
> 
> In the case of vectors, var->num_children would be
computed from n =
> v._M_impl._M_finish - v._M_impl._M_start and the
children would be created from
> *(v._M_impl._M_start+1), *(v._M_impl._M_start+2),
...*(v._M_impl._M_start+n).

I think it should be:
*(v._M_impl._M_start+0),...,*(v._M_impl._M_start+n-1).

> I guess a special variable object would need to be
created for n and when it
> was reported as changed bt -var-update, new/old
variable objects could
> accordingly be created/deleted.

I don't see why we need a separate variable object. If the
number of children
of a variable object changes, then -var-update can include
that variable object
in the result (and tell the new number of children). Now the
question is
whether the children that are no longer present should be
deleted, and whether
new children should be auto-created.

It is probably better to auto-delete varobjs corresponding
to the children
that are gone. Then, -var-update output will list those
children, with 'in_scope'
attribute mentioning varobj is gone. Frontend is most likely
to want those
varobjs to be gone, and doing this automatically saves
frontend complexity.

Note that even if frontend wants to hold to the value of
now-deleted child, for
some reason, it must do it explicitly. Suppose that we don't
auto-delete children,
and the number of children first decreases by one and then
increases by one.
The varobj that corresponds to the last original child now
is not accessible in any 
way. It's not accessible via children list of it's parent.
It's not accessible by
the name -- as the name got reused when new child is added.
So, we cannot
even get the value of that varobj.

I think that likewise, -var-update should create varobjs for
new children,
and return them -- we probably need a new attribute to
indicate that a varobj
was just created. This might sound like breaking frontends
not prepared to see
new varobjs in -var-update output. However, this dynamic
child behaviour will
happen only as result of explicit request from frontend.
It's natural to
give frontend a choice between 'raw' representation and
'pretty' representation,
and for compatibility, it's best to default to 'raw'. And if
frontend asks
gdb to use pretty representation for a varobj, or all varobj
of given type,
we can expect the frontend to property handle auto-created
varobjs.

Does this make sense?

- Volodya