Re: [RFC] Variable objects for STL containers

[Vladimir Prus <ghost at cs dot msu dot su>]

Doug Evans wrote:

> On Feb 17, 2008 12:18 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
>>
>> 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.
> 
> There's something I don't understand, and maybe you can help clear
> things up.  It seems like this approach is going down a path of
> hardwiring a lot of knowledge into gdb.  Solving this just for STL
> (and then only one version of STL) seems to be one piece of a general
> problem, why pick an unscalable solution?  If the knowledge was in a
> collection of dlopen'd .so (or some such), and users could provide
> more, then that might be reasonable.  [Setting aside use of python for
> this, I understand there is some pushback to going that route.  It'd
> be cool if the python support used the same interface, then one could
> have it both ways.   The python support is, of course, not just for
> this and one wouldn't want python to plug into gdb in a piecemeal
> fashion.  OTOH, if a clean solution could be found that let one solve
> this with either C[/C++] or python then that might be very useful.]

I think we should have Python as the official solution for those kinds
of things. While plugins might be nice, in order to implement plugins
you need gdb to install some headers one can compile against, and
maybe guarantee source and binary compatibility. Really, using Python,
where users don't have to compile anything, and where the interface for
extenders will be relatively small and capable of hiding gdb internals,
seems preferrable.

- Volodya