improving debugging experience ;)

Vladimir Prus ghost at
Fri Dec 9 10:50:07 UTC 2005

On Friday 09 December 2005 12:36, Christian Parpart wrote:
> On Friday 09 December 2005 00:46, Andreas Pakulat wrote:
> > On 08.12.05 22:58:42, Christian Parpart wrote:
> > > While in debugging mode, you're able to hover a symbol and get it's
> > > data dump, just like an item in the "Variables View", however,
> > > it is comprehensivily splitted up into a tree-alike popup stacked down
> > > to just where your hover the next symbol within this popup.
> > >
> > > While this is quite handy, there still is another thing I'm missing.
> >
> > Do you mean that this is in kdevelop already? Didn't see it yet, but
> > maybe just missed it :-)
> yup, you mixed it up. too bad :-P
> VS.NET 2005 really has this feature, and once you get in touch with it,
> it's really very much addictive.
> do you need screenshots?

Yes, or more detailed description. What you said sounds like the variable 
tooltip has a tree in it, but I have trouble picturing that.

> > > So now my idea is that KDevelop would just examine the data structure
> > > of a variable. If it hits a certain base class FOO containing a certain
> > > function BAR, then this one gets invoked and its return value is used
> > > for the pretty display.
> > > FOO and BAR shall be (of course) configurable, only one BAR per FOO and
> > > multiple type of FOOs.
> >
> > I'm not a debugger expert, but I think this is already done today and
> > you can do it yourself. For example for QString you get the string value
> > in the variable view if you include the gdb-macros from the kdesdk
> > package. I think the same is true for other Qt3 containers, like QMap
> > and QList, even though I'm currently not sure how they appear in the
> > variable view.
> >
> > If you look at those macros you can see that there's no "magic"
> > happening, just some "interpretation" of the data in the "d" pointers of
> > the classes (like QString, QMap and so on).
> >
> > > Is this even possible from a kdevelop/gdb technical point of view?
> >
> > The question is: Who is skilled enough with gdb to write this for each
> > and every framework?
> make it configurable by GDB in form of a listbox containing base class
> names. each of them can be configured to contain a method to be invoked on
> display. Think of a list like this:
>  * [SWL] TObject -> toString().c_str()
>  * [STL] std::string -> c_str()
>  * [Qt3] QObject -> toString().however()
>  * [boost] boostBaseClass -> theirRespectiveToCString()
> you get the idea on where I'd like to point you?

Yes, this all is reasonable, but we're doing to some limitations in gdb.

First, it sometimes says local variable exists before its constructor is 
called. So, calling member functions might result in crash.

Second, I don't know how to query gdb if a given type is derived from some 
base type. 

I'll try to research this, but if somebody has any ideas, I'm all ears.

- Volodya

More information about the KDevelop-devel mailing list