This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH:MI] Return a subset of a variable object's children


Nick Roberts wrote:

>  > > step size (stride) other than one.
>  > 
>  > I'm not sure what the stride would be used for.  Maybe something like
>  > printing all even indexes of an array for example?  In any case, it is a
>  > pretty simple addition, and no one is forced to use it, so I'm only asking
>  > to understand better.
> 
> Yes, I think its just another way to sample a large array.  ISTR dbx allows
> printing array slices in this way.

And is this behaviour particularly useful?

>  > > 2008-04-27  Nick Roberts  <nickrob@snap.net.nz>
>  > > 
>  > >       * mi/mi-cmd-var.c (mi_cmd_var_list_children): Add options to select
>  > >       a subset of children.
>  > > 
>  > >       * varobj.h (varobj_list_children): Declare new parameters.
>  > > 
>  > >       * varobj.c (struct varobj): New member current_children.
>  > >       (varobj_list_children): Create any new varobjs for children
>  > >       specified by mi_cmd_var_list_children.
>  > >       (create_child): Add parameter real_index.  Use it.
>  > > 
>  > 
>  > 
>  > I have a concern about the ordering of children.  I think not having a
>  > constant ordering for the children could prove a problem.  For example, I
>  > think the algorithm proposed will fail if a child varObj is deleted by the
>  > user.  I believe deleting a varObj inserts NULL in its current position,
>  > however, the algo always inserts at the end, so it will miss the available
>  > deleted entry.
> 
> You're probably right about ordering, and deletion does cause a segmentation
> fault.
> 
>  > Also, the double loop may prove to be slow for large number of children.
> 
> I was thinking that only a small number of children would ever exist
> simultaneously.  Scrolling might make that a larger number but maybe
> it could be arranged to delete children that go out of view.

I wonder if deleting children that are not visible is possible/desirable.
In Qt, item data is requested only when item is drawn. I think SWT's Tree can be
configured the same way. However, I don't think I saw any way, in either, to
detect than an item is no longer visible. Marc, can you tell if SWT allows that?

Even if technically possible, is this a desirable thing? I think the the primary
goal of incremental fetch is that if you happen to have std::vector with 200 children,
then display of it won't fill your entire screen with children of a single variable.
With incremental fetch, you can look at the children only if you're really interested.
On the other hand, I don't think keeping 200 varobjs in GDB is too expensive. And if
we talk about 10000 children, then well, I don't think standard variable display widget
is gonna be very good. Even if you delete varobjs that are not visible, it's too hard
to find anything interesting among 10000 elements.

 
>  > I was thinking that we could keep order of children as they are defined
>  > (current behaviour) but not fill them all, until requested.
>  > We could create the full Vector of children as is done now by
>  > 
>  >   while (VEC_length (varobj_p, var->children) < var->num_children)
>  >     VEC_safe_push (varobj_p, var->children, NULL);
> 
> I guess this would remove the need for a second loop but it seems wasteful on
> memory.  Previously children variable objects were stored as a linked list and,
> as I have said before, I do think this is more suitable as objects can then be
> inserted and removed at any point in the sequence of children.

Please feel free to implement generic list datastructure in C, or rewrite gdb in C++.
So far, using vector proved to be big convenience.

> 
>  > but only actually create the children that have been requested by the user.
>  > I'm not sure how much efficiency there is by allocating the memory before
>  > hand?  Also, is there no way to grow the vector by more than a single point
>  > at a time?
> 
> Like resize with STL vectors?  I'm not aware of one.

VEC_safe_grow

- Volodya



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]