| Summary: | gdb pretty printing any objects | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Gaël de Chalendar (aka Kleag) <kleagg> |
| Component: | CPP Debugger | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED LATER | ||
| Severity: | wishlist | CC: | toroklev |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Mandrake RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Gaël de Chalendar (aka Kleag)
2004-12-03 09:52:36 UTC
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 |