General Debugger Framework

[Niko Sams]

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.
And if I commit the debugcontroller there will be the
debugcontroller-actions in the
run menu - even if you use the playground debugger - that would mean
ever action twice :(

Niko