KDE/kdevelop/languages/cpp/debugger
Andreas Pakulat
apaku at gmx.de
Fri Dec 14 01:16:01 UTC 2007
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.
Andreas
--
Beware the one behind you.
More information about the KDevelop-devel
mailing list