General Debugger Framework

[Mario Chacon]

Hello:
One of the feature of the next  Fedora 11 release there is an improvement in
the debugger using archer (https://fedoraproject.org/wiki/Features/Archer),
Is this improvements going to be reflected in the kdevelop4?

Thank you..
masch...
Salu2...

On Mon, Mar 23, 2009 at 6:29 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 23.03.09 21:03:39, Niko Sams wrote:
> > Hi,
> >
> > To support more debuggers than just gdb we need a generic debugger
> > framework with
> > a common UI. I started this with a first patch
> > (http://reviewboard.kde.org/r/379/) - you can't
> > call it framework :D it's just a bunch of common actions - as this is
> > the most annoying if
> > you have those actions for every debugger duplicated in the gui.
> > I'm currently also working on a XDebug (http://xdebug.org a php
> > debugger) debugger implementation
> > that uses the dbgp protocol - a generic protocol.
> >
> > So a few things have to be cleared:
> > - what debugger will get ported to that framework?
>
> Time will tell, currently both gdb-plugins have deficiencies.
>
> > - is this planned after the first kdevelop release?
>
> kdevplatform doesn't guarantee BC or SC until we feel like it (i.e. 2.0
> release at most). So even if we start for 1.0 its fine if we completely
> scratch everything and redo it for the next release.
>
> > - general direction of the debugger framework
> >    apaku proposed the debugger plugin should not have access to
> >    any gui components. That would mean we have to think about models
> >    for stack/variable-view/breakpoints and so on. Advantage is a common
> UI
> >    that just has to be implemented once.
> >    However not all debuggers have the same features (gdb can show memory
> stuff
> >    where xdebug won't do that)
>
> I have to admit that I may be a bit biased by Eclipse debugger framework
> (as thats the only one I ever got involved with). I'm not sure how they do
> things like memory-debugging (if thats supported at all), but thats
> something that maybe can still be supplied by the debugger plugin on its
> own.
>
> The part that the debugger plugin really should only deliver data for
> (IMHO) is for the "normal" stuff:
>
> - variables (local+global)
> - watches
> - threads
> - frames (and framestack)
> - position information for the current frame
> - hooks to tell the debugger plugin to do things like
>  step,pause,continue,step-return etc.
> - API to tell the plugin where breakpoints are set (or the plugin fetches
>  that list from the debugger controller)
>
> If we have that it would be a good start and we can think about extending
> it to more specialized things like memory-debugging and stepping individual
> assembler instructions later on.
>
> Andreas
>
> --
> You will have domestic happiness and faithful friends.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090323/c43a9faa/attachment.html>