General Debugger Framework

[Andreas Pakulat]

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.