KDE/kdevelop/languages/cpp/debugger

Andreas Pakulat apaku at gmx.de
Fri Dec 14 01:21:19 UTC 2007


On 14.12.07 02:16:01, Andreas Pakulat wrote:
> On 14.12.07 12:01:31, Hamish Rodda wrote:
> > On Fri, 14 Dec 2007 09:51:20 am Andreas Pakulat wrote:
> > > On 13.12.07 22:26:14, Hamish Rodda wrote:
> > > > Start on new way of providing specialised debugging views for certain
> > > > objects - first example is parsing of QString (not yet working). One
> > > > day soon you should be able to write customised views using
> > > > plugins, that's going to be awesome :)
> > >
> > > Didn't look at the code yet, but IMHO it makes more sense to implement
> > > this inside the gdb plugin as a simple mapping of type-names to gdb
> > > commands (or list of commands). That way its _very_ easy to register
> > > your own type for printing, without the need to do any coding at all.
> > > And KDevelop doesn't have to re-invent the wheel and can just depend on
> > > the existing gdb macros from kdesdk to print Qt4 and Qt3 structures.
> > 
> > This is not just about returning a smart value, it's also about showing 
> > different children (ie. making list/set/map etc members accessible).  Also, 
> > not everything can be accomplished with a single gdb command, and you 
> > couldn't provide any processing for multiple commands with the system you're 
> > suggesting.  Also, you couldn't specify how to format the output from gdb 
> > (QString char data has to be processed first).  Eventually I also want to 
> > implement casting features so when you're shown a base class, you can easily 
> > get to the subclass features.
> 
> Well, I meant macro's as well. But IIRC the debugger doesn't work when
> you just execute something like printf "foo" in gdb right? So macros
> like printq4string are not going to work.
> 
> Still IMHO we need a way to make this extendable to custom type without
> having to compile a plugin. How about defining a scripting interface
> which allows to do this, i.e. people can register a script with a type
> information and then the debugger executes the script. Thats far easier
> than having to setup a plugin project and build it. Its also easier to
> write as you don't need to restart KDevelop to test a new version.

PS: An easy way of connecting a type with a way to print/display that type in
the variable tree is something that has been requested from users over
and over again and many of them pointed at MSVC which does allow exactly
this.

Andreas

-- 
Write yourself a threatening letter and pen a defiant reply.




More information about the KDevelop-devel mailing list