General Debugger Framework

[Vladimir Prus]

On Tuesday 24 March 2009 21:56:35 Niko Sams wrote:
> On Mon, Mar 23, 2009 at 10: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.
> very good :D
> 
> 
> >> - 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)
> yep, that will do it for most debuggers.
> 
> > 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.
> that should always be possible per plugin.
> 
> So where should I commit the platform debugcontroller and the adapted
> gdb debugger?
> In it's current state it is really broken so I don't know if trunk is ok.

Uhm. Given that the current trunk gdb plugin somewhat works, I'd much
rather it not be broken. Is there any chance to arrive at incremental
commit that does not make things more broken?

- Volodya