Version: (using KDE KDE 3.3.2KDE 1.2) Installed from: Mandrake RPMsMandrake RPMs It would be very useful if the gdb interface could pretty print content of STL objects. For example, a std::string could be displayed as is, a std::vector of n elements could be diplayed as a list of n elements unfoldable and its elements kdevelop could try to display the individual elements at demand. When you debug, it's generally because some memory has bad values, so some care should be taken to avoid crashing of the debugger part itself when trying to access to object to display them, but some things could certainly be done to avoid to display only the internal structure of STL objects.
This is very desirable, but might be hard to implement. The problem is that "info locals" command of gdb shows all local variables, even those which are not yet "live" and for which constructor is not yet executed. So, any code to pretty print cannot call any method, as they might crash. I have no idea yet how to detect if variable is initialized and if we can recover from a crash in called method. Without calling methods, we'd have to dig into internal structures and again, if the class in non-initialized, this can lead to bad results.
I second to STL prettier show in debug window. I found http://www.stanford.edu/~afn/gdb_stl_utils/ so far, but I have some problems with using it.
I found another useful source for debugging STL with gdb debugger : http://gcc.gnu.org/ml/libstdc++/2006-08/msg00009.html. It might be helpful for implementing.
Some more votes for this bug. By the way, here's another link which may be of use when dealing with this issue: http://staff.science.uva.nl/~gilad/stl/stl_gdb.html
This will happen as soon as gdb supports scripting.
Is gdb the blocking factor here? It has user defined commands: http://sourceware.org/gdb/current/onlinedocs/gdb_21.html As an example, the Apache httpd project supplies commands for pretty printing of its own data structures. http://svn.apache.org/viewvc/httpd/httpd/trunk/.gdbinit?view=markup A google search for "gdbinit STL" shows useful results. However I suspect the scripts are tightly coupled to the STL implementation in use. If we could detect at runtime if libstdc++ was in use, then we could safely proceed and use scripts with deep knowledge of libstdc++. KDevelop would then consume the data and present it the GUI. For other STL variants, e.g. STLport, Apache STDCXX alternate GDB scripts could be developed. However that shouldn't be KDevelop's remit, each STL implementation should aim to ship GDB (and others - dbx?) STL pretty printing scripts. KDevelop's task would be to integrate with these scripts and present the output in the GUI.
yes gdb is the blocking part. The problem with these functions (which you can also have for qstrings and others) is AFAIK that they don't fit well with anything but plain-text-visualization of components. The scripting approach (inside gdb) would allow to also provide contents of arrays or general structures (like hiding the d-pointer in Qt classes) very easily. Thats why we're waiting for gdb to go forward with this.
*** Bug 129089 has been marked as a duplicate of this bug. ***
changing the summary a bit so its more general