Posted Oct 9, 2009 9:07 UTC (Fri) by nix (subscriber, #2304)
In reply to: GDB 7.0 released by njs
Parent article: GDB 7.0 released
Well, another problem is that GDB tended to use the full expanded names for all these types, rather than hiding things which are not referenced in the source code but only via default template parameters (very common: e.g. allocators in the STL). This tends to make trivial things like 'cout' or 'list<string>' into multiline what-the-hell-is-that horrors. (This was fixed for diagnostic output some time ago, but I haven't done much C++ debugging recently so I'm not sure if GDB fixed it similarly.)
Posted Oct 15, 2009 8:26 UTC (Thu) by elanthis (guest, #6227)
[Link]
A lot of that is GCC's fault, really. GDB can only present the information present in the debug info, so if GCC is just slapping in the fully expanded instantiated types, then that's all GDB can give the user.
GDB needs a big push in the debug info department. It could use a big push in the compile time error quality, too, for that matter.
GDB 7.0 released
Posted Oct 15, 2009 8:56 UTC (Thu) by jwakely (subscriber, #60262)
[Link]
A lot of that is GCC's fault, really. GDB can only present the information present in the debug info, so if GCC is just slapping in the fully expanded instantiated types, then that's all GDB can give the user.
GCC has to "slap in" the full type name for the linker, typedefs do not affect the name the linker uses.
GDB needs a big push in the debug info department.
Posted Oct 15, 2009 11:33 UTC (Thu) by jwakely (subscriber, #60262)
[Link]
GDB can only present the information present in the debug info, so if GCC is just slapping in the fully expanded instantiated types, then that's all GDB can give the user.
... and this isn't true. GDB can show a more useful representation of data structures than simply listing all the bases and members, and that's exactly what the new python pretty printing does.