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: [RFC] Variable objects for STL containers


 > I don't particularly like the use of this special child to indicate
 > the number of children. We already have a mechanism to report the number of
 > children and having yet another mechanism seems just confusing.

GDB needs some way to report the extra children in -var-update but I'm not
worried what way is used.  I wanted to establish that using gcc internals was
OK and the feasibility of doing this within the C code.

 > Of course, if we use the existing mechanism then -var-update will have
 > to be able to report the variable objects that have the number of children
 > changed -- and a frontend will have to be adjusted to handle that mechanism.

We should probably add an option to Gdb to process the STL container as a
variable object in the normal way and make that the default.  That also will
mean we can write code for STL containers in an incremental fashion, provided
we explain this in the manual.

 > However, it's not harder for frontend than the approach above. In fact,
 > using the approach above, how will frontend know that a varobj is
 > the special one that reports the number of children? I don't see anything
 > in the output above to indicate the special role of var1.0

We could just add another field, stl="1" say to the output of var-update,
-var-list-children, etc.

 >...
 > For scripting purposes, and for simplicity in general, in better if one
 > has to implement just one function for any new type. Further, while mapping
 > from index to value is simple for std::vector, it's much less trivial for
 > list, and even less trivial for map. We better not traverse the list when
 > getting each element.
 > 
 > So, I will prefer a mechanism where one can write a function taking a
 > varobj.  That function should be able to compute the list of children, and
 > then create varobj children specifying the value directly. So, in case of
 > std::list, we'd traverse the list once, get the values and create varobjs
 > with those values. Of course, we'd need some support -- in particular a
 > version of create_child that takes a value. We will need to change
 > varobj_update so that it knows not to call value_of_child on children of
 > special varobj, as well.

I think for lists, maps etc, Gdb needs to traverse the internal data structure
each to see if there are new elements or if any have been deleted.  This need
only be done when execution stops, of course, but I guess it could be expensive
for stepping.

The ideas here are just for discussion and I'm more than happy to look at any
changes you might like to make.


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


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