This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Variable objects for STL containers
> 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?
This is not any STL, but Gcc's STL. Gdb and Gcc are both part of the GNU
project so should possibly have a special relationship. By unscaleable, I
guess you mean not general. Hardwiring is a worry but I have briefly discussed
this subject on the Gcc and been assured that the code used is quite stable.
It's also a matter of keeping Gcc developers informed about intended use of
Gcc internals.
> If the knowledge was in a
> collection of dlopen'd .so (or some such), and users could provide
> more, then that might be reasonable.
If you know how to do it, that would be an improvement. Presumably it could
also be done at a later stage, adapting any hardwired solution.
> [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 don't really understand how the python support will be implemented but I
don't see why variable objects for STL containers should require Python
libraries to be present.
--
Nick http://www.inet.net.nz/~nickrob