Variable objects and STL containers

Variable objects and STL containers

[Nick Roberts]

Using variable objects, if I display a watch expression for an STL container, e.g.

  vector<int> v (3);
  v[0] = 1;
  v[1] = 11;
  v[2] = 22;

in Emacs, I get something like this:

v std::vector<int,std::allocator<int> >
    std::_Vector_base<int,std::allocator<int> > std::_Vector_base<int,std::allocator<int> >
      public	 
        _M_impl	std::_Vector_base<int,std::allocator<int> >::_Vector_impl
          std::allocator<int>	std::allocator<int>
            __gnu_cxx::new_allocator<int>	{...}
          public	 
            _M_start             int * 	    0x804c008
              *_M_start	                    0
            _M_finish	         int *	    0x804c014	
              *_M_finish                    135153	
            _M_end_of_storage    int *      0x804c014
              *_M_end_of_storage            135153	

which is a bit meaningless to the end user.  This is for gcc, and I guess other
compilers store STL containers differently.  In this case, I know where the
values are really stored:

 v._M_impl._M_start	int *	0x804c008
 *v._M_impl._M_start		1
 *(v._M_impl._M_start+1)	11
 *(v._M_impl._M_start+2)	22

(gdb) p v._M_impl._M_finish - v._M_impl._M_start
$1 = 3

and it would be better to display these.

I have two questions:

1) Does GDB know what compiler was used to create an object file/executable?

2) _M_impl, _M_start are gcc internals and I guess they could change (like CLI!)
   Is it meaningful to ask on the gcc list for a formal interface to these details?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Variable objects and STL containers

[Vladimir Prus]

Nick Roberts wrote:

> 
> Using variable objects, if I display a watch expression for an STL container, e.g.
> 
>   vector<int> v (3);
>   v[0] = 1;
>   v[1] = 11;
>   v[2] = 22;
> 
> in Emacs, I get something like this:
> 
> v std::vector<int,std::allocator<int> >
>     std::_Vector_base<int,std::allocator<int> > std::_Vector_base<int,std::allocator<int> >
>       public
>         _M_impl       std::_Vector_base<int,std::allocator<int> >::_Vector_impl
>           std::allocator<int> std::allocator<int>
>             __gnu_cxx::new_allocator<int>     {...}
>           public
>             _M_start             int *            0x804c008
>               *_M_start                           0
>             _M_finish          int *      0x804c014
>               *_M_finish                    135153
>             _M_end_of_storage    int *      0x804c014
>               *_M_end_of_storage            135153
> 
> which is a bit meaningless to the end user.  This is for gcc, and I guess other
> compilers store STL containers differently.  In this case, I know where the
> values are really stored:
> 
>  v._M_impl._M_start   int *   0x804c008
>  *v._M_impl._M_start          1
>  *(v._M_impl._M_start+1)      11
>  *(v._M_impl._M_start+2)      22
> 
> (gdb) p v._M_impl._M_finish - v._M_impl._M_start
> $1 = 3
> 
> and it would be better to display these.
> 
> I have two questions:
> 
> 1) Does GDB know what compiler was used to create an object file/executable?
> 
> 2) _M_impl, _M_start are gcc internals and I guess they could change (like CLI!)
>    Is it meaningful to ask on the gcc list for a formal interface to these details?

Technically, there is formal interface, called iterators, provided by the
C++ standard. I don't have the slightest confidence in gdb not falling over
if you try to use them, though.

We discussed using Python scripting for that; in fact, I have a patch locally
that will make 

        -var-evaluate-expression V 

for a vector print something like:

        [1,2,3]

I'm working on making those element the children of the variable object,
but it's not done yet.

- Volodya

Re: Variable objects and STL containers

[Nick Roberts]

 > > 2) _M_impl, _M_start are gcc internals and I guess they could change (like
 > >    CLI!)  Is it meaningful to ask on the gcc list for a formal interface
 > >    to these details?
 > 
 > Technically, there is formal interface, called iterators, provided by the
 > C++ standard. I don't have the slightest confidence in gdb not falling over
 > if you try to use them, though.

Are iterators available to GDB, or just the executable?  I only seem able to
access those methods which are used by my program, e.g.,

(gdb) p v.size ()
$3 = 3

but

(gdb) p v.rbegin ()
Cannot evaluate function -- may be inlined

 > We discussed using Python scripting for that; in fact, I have a patch locally
 > that will make 
 > 
 >         -var-evaluate-expression V 
 > 
 > for a vector print something like:
 >
 >         [1,2,3]

Does this work for programs compiled by any compiler, or just gcc?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Variable objects and STL containers

[Vladimir Prus]

Nick Roberts wrote:

>  > > 2) _M_impl, _M_start are gcc internals and I guess they could change (like
>  > >    CLI!)  Is it meaningful to ask on the gcc list for a formal interface
>  > >    to these details?
>  > 
>  > Technically, there is formal interface, called iterators, provided by the
>  > C++ standard. I don't have the slightest confidence in gdb not falling over
>  > if you try to use them, though.
> 
> Are iterators available to GDB, or just the executable? I only seem able to 
> access those methods which are used by my program, e.g.,
> 
> (gdb) p v.size ()
> $3 = 3
> 
> but
> 
> (gdb) p v.rbegin ()
> Cannot evaluate function -- may be inlined

Well, that what I mean by 'falling over', in part ;-) I would not
be suprised if attempt to increment an iterator, using the overloaded
operator++, also will fail.

>  > We discussed using Python scripting for that; in fact, I have a patch locally
>  > that will make
>  > 
>  >         -var-evaluate-expression V
>  > 
>  > for a vector print something like:
>  >
>  >         [1,2,3]
> 
> Does this work for programs compiled by any compiler, or just gcc?

For each different STL implementation, you'd need different Python code
to render vector.

- Volodya

Re: Variable objects and STL containers

[Daniel Jacobowitz]

On Tue, Feb 05, 2008 at 07:33:40PM +1300, Nick Roberts wrote:
> Are iterators available to GDB, or just the executable?  I only seem able to
> access those methods which are used by my program, e.g.,

That's generally correct; there's nothing in the debug info explaining
what template or inline methods do which are not instantiated
out-of-line somewhere in the program.  With optimization you may not
be able to call them even if they are used.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Variable objects and STL containers

[Nick Roberts]

 > > Are iterators available to GDB, or just the executable?  I only seem able
 > > to access those methods which are used by my program, e.g.,
 > 
 > That's generally correct; there's nothing in the debug info explaining
 > what template or inline methods do which are not instantiated
 > out-of-line somewhere in the program.  With optimization you may not
 > be able to call them even if they are used.

Would it be possible for the gcc developers to add that information?
I mean with a special option, like -g3 means include macro information.

Alternatively would it be possible to share code for those methods with
Gdb, as with the bfd library?

Creating variable objects using internals wasn't so hard for vectors but
it gets a bit more tricky with lists.  

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Variable objects and STL containers

[Nick Roberts]

 > Creating variable objects using internals wasn't so hard for vectors but
 > it gets a bit more tricky with lists.  

Actually it looks doable for lists, maps etc if the children of a variable
object were stored as a list rather than a vector.  This is so that a new
child can be added, or an old one deleted, at any point in the list.

Ironically, the children were previously stored in a linked list and I guess
vectors were used because Nathan Sidwell has created an API in C for them.
There doesn't appear to be a similar API for lists, but since they are more
flexible, would it be possible to revert var->children to a linked list?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Variable objects and STL containers

[Vladimir Prus]

On Sunday 17 February 2008 03:19:14 Nick Roberts wrote:
>  > Creating variable objects using internals wasn't so hard for vectors but
>  > it gets a bit more tricky with lists.  
> 
> Actually it looks doable for lists, maps etc if the children of a variable
> object were stored as a list rather than a vector.  This is so that a new
> child can be added, or an old one deleted, at any point in the list.
> 
> Ironically, the children were previously stored in a linked list and I guess
> vectors were used because Nathan Sidwell has created an API in C for them.
> There doesn't appear to be a similar API for lists, but since they are more
> flexible, would it be possible to revert var->children to a linked list?

I'm afraid I don't see any such flexibility. Can you clarify? The vectors were used
because they allowed to eliminate lots of custom list handling code, and
I'm reluctant to go back.

- Volodya

Re: Variable objects and STL containers

[Nick Roberts]

 > > Actually it looks doable for lists, maps etc if the children of a variable
 > > object were stored as a list rather than a vector.  This is so that a new
 > > child can be added, or an old one deleted, at any point in the list.
 > > 
 > > Ironically, the children were previously stored in a linked list and I
 > > guess vectors were used because Nathan Sidwell has created an API in C for
 > > them.  There doesn't appear to be a similar API for lists, but since they
 > > are more flexible, would it be possible to revert var->children to a
 > > linked list?
 > 
 > I'm afraid I don't see any such flexibility. Can you clarify? The vectors
 > were used because they allowed to eliminate lots of custom list handling
 > code, and I'm reluctant to go back.

I can understand that you are reluctant to go back but I'm surprised that you
don't see the convenience.  Until now the number of children has been fixed, so
vectors are probably a natural choice.  With STL containers the number changes
and and it becomes advantageous to use lists.  Taking maps, for example, they
appear to be stored as binary trees and GDB can traverse the tree (inorder) to
examine all the nodes.  When it finds a new one, it needs to create a new child
*at that point* in the sequence of children.  A vector can't do that.  It can
only add or remove them at the end, so a list must be used.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Variable objects and STL containers

[Vladimir Prus]

On Sunday 17 February 2008 22:54:49 you wrote:
>  > > Actually it looks doable for lists, maps etc if the children of a variable
>  > > object were stored as a list rather than a vector.  This is so that a new
>  > > child can be added, or an old one deleted, at any point in the list.
>  > > 
>  > > Ironically, the children were previously stored in a linked list and I
>  > > guess vectors were used because Nathan Sidwell has created an API in C for
>  > > them.  There doesn't appear to be a similar API for lists, but since they
>  > > are more flexible, would it be possible to revert var->children to a
>  > > linked list?
>  > 
>  > I'm afraid I don't see any such flexibility. Can you clarify? The vectors
>  > were used because they allowed to eliminate lots of custom list handling
>  > code, and I'm reluctant to go back.
> 
> I can understand that you are reluctant to go back but I'm surprised that you
> don't see the convenience.  Until now the number of children has been fixed, so
> vectors are probably a natural choice.  With STL containers the number changes
> and and it becomes advantageous to use lists.  Taking maps, for example, they
> appear to be stored as binary trees and GDB can traverse the tree (inorder) to
> examine all the nodes.  When it finds a new one, it needs to create a new child
> *at that point* in the sequence of children.  A vector can't do that.  It can
> only add or remove them at the end, so a list must be used.

To be picky, vector can insert and remove elements in the middle, but that's O(N)
operation. But in fact, that only matters if you happen to already know that
an element was added at a certain position in the middle, which I think we don't.
Instead, we get to traverse the list, and then construct a sequence of values, then
compare the changes and report them. Suppose the old values were:

	1   2   3  4

and new values are 

	1   2   5  3  4

We can either report that varobj 2 changed value from 3 to 5, that varobj 3
changed value from 4 to 3 and that new varobj was added at end. In this case,
using vector is not a problem at all.

Or we can report that new varobj was added at position 5. This sounds more 
attractive, but it's harder to properly detect minimal changes, and it's
harder to communicate such change to gdb. And, it seems like a simple
algorithm to detect changes will work just fine with vectors.

- Volodya

Re: Variable objects and STL containers

[Daniel Jacobowitz]

On Fri, Feb 15, 2008 at 10:23:28PM +1300, Nick Roberts wrote:
> Would it be possible for the gcc developers to add that information?
> I mean with a special option, like -g3 means include macro information.

I don't think so.  There is no useful way to represent their actions;
you'd need a compiler to some intermediate language, probably the
DWARF stack machine.

> Alternatively would it be possible to share code for those methods with
> Gdb, as with the bfd library?

They're written in C++ and templated for every user type that uses
them.  So, not this either.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Variable objects and STL containers

[Mark Kettenis]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date:  Tue, 05 Feb 2008 09:16:53 +0300
> 
> Technically, there is formal interface, called iterators, provided by the
> C++ standard. I don't have the slightest confidence in gdb not falling over
> if you try to use them, though.

That means that you actually have to call functions in the inferior,
which might modify state you don't want to modify.  And of course it
doesn't work at all for core dumps.

> We discussed using Python scripting for that; in fact, I have a patch locally
> that will make 
> 
>         -var-evaluate-expression V 
> 
> for a vector print something like:
> 
>         [1,2,3]
> 
> I'm working on making those element the children of the variable object,
> but it's not done yet.

Still this means that you'll need to write python code for each and
every STL implementation, and play catchup whenever the implementation
is changed.  I guess the only way to get this to work is to connvince
the GCC people to maintain the python code together with libstdc++.

Re: Variable objects and STL containers

[Vladimir Prus]

On Tuesday 05 February 2008 14:31:07 Mark Kettenis wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date:  Tue, 05 Feb 2008 09:16:53 +0300
> > 
> > Technically, there is formal interface, called iterators, provided by the
> > C++ standard. I don't have the slightest confidence in gdb not falling over
> > if you try to use them, though.
> 
> That means that you actually have to call functions in the inferior,
> which might modify state you don't want to modify. 

In theory, all called functions are supposed to be const member functions,
so should not modify anything. In practice, they might still touch some
memory (if that does not modify logical state of the object), and if 
we're trying to calling functions on non-yet-initialized object,
that might corrupt things.

(And IIUC, gcc still won't tell us when a C++ object is initialized).

> And of course it 
> doesn't work at all for core dumps.

Yes.

> > We discussed using Python scripting for that; in fact, I have a patch locally
> > that will make 
> > 
> >         -var-evaluate-expression V 
> > 
> > for a vector print something like:
> > 
> >         [1,2,3]
> > 
> > I'm working on making those element the children of the variable object,
> > but it's not done yet.
> 
> Still this means that you'll need to write python code for each and
> every STL implementation, and play catchup whenever the implementation
> is changed.

In case of std::vector in GCC, I doubt many changes are coming.

> I guess the only way to get this to work is to connvince 
> the GCC people to maintain the python code together with libstdc++.

Of course that would be ideal. However, libstdc++ is not the only
standard library, and anyway -- having the mechanism is more important
that who gets to write python code.

- Volodya

Re: Variable objects and STL containers

[Daniel Jacobowitz]

On Tue, Feb 05, 2008 at 12:31:07PM +0100, Mark Kettenis wrote:
> > We discussed using Python scripting for that; in fact, I have a patch locally
> > that will make 
> > 
> >         -var-evaluate-expression V 
> > 
> > for a vector print something like:
> > 
> >         [1,2,3]
> > 
> > I'm working on making those element the children of the variable object,
> > but it's not done yet.
> 
> Still this means that you'll need to write python code for each and
> every STL implementation, and play catchup whenever the implementation
> is changed.  I guess the only way to get this to work is to connvince
> the GCC people to maintain the python code together with libstdc++.

Right.  That's what I would like to happen; and since GCC is both a
GNU project and widely used with GDB, I think it will be easy to
convince them.  I envision these scripts going in
/usr/share/gdb/packages or something similar to that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Variable objects and STL containers

[Nick Roberts]

 > We discussed using Python scripting for that; in fact, I have a patch locally
 > that will make 
 > 
 >         -var-evaluate-expression V 
 > 
 > for a vector print something like:
 > 
 >         [1,2,3]
 > 
 > I'm working on making those element the children of the variable object,
 > but it's not done yet.

What will you do when the number of elements increases/decreases.  Will
Gdb create/delete variable objects for these children automatically?  Or
will the frontend be prompted?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Variable objects and STL containers

[Vladimir Prus]

On Friday 08 February 2008 03:52:45 you wrote:
>  > We discussed using Python scripting for that; in fact, I have a patch locally
>  > that will make 
>  > 
>  >         -var-evaluate-expression V 
>  > 
>  > for a vector print something like:
>  > 
>  >         [1,2,3]
>  > 
>  > I'm working on making those element the children of the variable object,
>  > but it's not done yet.
> 
> What will you do when the number of elements increases/decreases.  Will
> Gdb create/delete variable objects for these children automatically?

I anticipate that -var-update will:

1. Create new children, and report them.
2. Report children that are now gone, possibly deleting them.

- Volodya

Re: Variable objects and STL containers

[Nick Roberts]

 > > What will you do when the number of elements increases/decreases.  Will
 > > Gdb create/delete variable objects for these children automatically?
 > 
 > 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.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Variable objects and STL containers

[Vladimir Prus]

On Sunday 10 February 2008 07:27:44 Nick Roberts wrote:
>  > > What will you do when the number of elements increases/decreases.  Will
>  > > Gdb create/delete variable objects for these children automatically?
>  > 
>  > 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.

- Volodya

Re: Variable objects and STL containers

[Daniel Jacobowitz]

On Sun, Feb 10, 2008 at 10:10:48AM +0300, Vladimir Prus wrote:
> 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.

Maybe you should put what you have out on a branch?

Or if you're using svk for this maybe we can set up a scratch SVN
repository for it somewhere.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Variable objects and STL containers

[Vladimir Prus]

On Sunday 10 February 2008 20:52:27 Daniel Jacobowitz wrote:
> On Sun, Feb 10, 2008 at 10:10:48AM +0300, Vladimir Prus wrote:
> > 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.
> 
> Maybe you should put what you have out on a branch?
> 
> Or if you're using svk for this maybe we can set up a scratch SVN
> repository for it somewhere.

I can try pushing this into a public git repository.

- Volodya

Re: Variable objects and STL containers

[Doug Evans]

On Feb 10, 2008 9:52 AM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Feb 10, 2008 at 10:10:48AM +0300, Vladimir Prus wrote:
> > 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.
>
> Maybe you should put what you have out on a branch?
>
> Or if you're using svk for this maybe we can set up a scratch SVN
> repository for it somewhere.

That would be a good idea, I know some folks that would like to help
work on this.

Re: Variable objects and STL containers

[Doug Evans]

On Feb 9, 2008 11:10 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
> 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.

Is there a design doc for what python support will look like?

Re: Variable objects and STL containers

[Vladimir Prus]

On Sunday 10 February 2008 22:43:44 Doug Evans wrote:
> On Feb 9, 2008 11:10 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
> > 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.
> 
> Is there a design doc for what python support will look like?

Not yet; I shall post some initial ideas.

- Volodya

Re: Variable objects and STL containers

[Nick Roberts]

 > >  > 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.nz/~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]);

Re: Variable objects and STL containers

[Vladimir Prus]

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

Re: Variable objects and STL containers

[Daniel Jacobowitz]

On Mon, Feb 11, 2008 at 12:11:36PM +0300, Vladimir Prus wrote:
> 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.

I suggest we wait until you have something implemented, and then see
how various front ends (emacs, kdevelop, Eclipse) react to it.  If
they break, we can limit the new behavior to mi3.

I want to finish up the quoting changes I discussed last year for mi3,
too...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Variable objects and STL containers

[Nick Roberts]

 > > 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.

So if you don't have Python, your patch for variable objects for STL containers
will not work.

 > > 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.

Can they be presented separately?

 > > 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).

Yes.

 > > 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). 

I just think it might mean that the output of -var-update need not change.
If n changes the frontend can create/delete the extra/old variable objects.

 > 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.

I think it may involve a bigger change to the MI output.

 > 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 don't think we should worry about keeping the value of STL members that
have been deleted - at least for now.

 > 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.

AFAIK, if three new members are created and two deleted, all the executable
needs to know is that there is one new member.  That's why I think it may be
simple to just have a special variable object that tells the front end when the
number of members changes.

 > 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.

An option for this sounds like a good idea.

 > Does this make sense?

Overall, it does.  I think it would be a good idea to allow room for possible
changes in implementation detail.

-- 
Nick                                           http://www.inet.net.nz/~nickrob