General Debugger Framework

[Andreas Pakulat]

On 24.03.09 19: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:
> >> - 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

Anything else would be insane, most of it is completely new code (and
some is being refactored _right now_) and we don't yet have much
experience with writing such a framework
 
> > 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.

How about just putting the stuff in kdevplatform in for now? i.e. let
the gdb plugin for now as is, but start working on separating gui from
"backend" and creating the interfaces as I explained above. You can of
course use the new things in your xdebug plugin, so that you have at
least once reference implementation. I was planning on revamping the run
support this weekend (unless real life strikes, which might happen
eventually), which would possibly change some things for debugger
plugins as well. (being able to provide config for a runnable, moving
debug-actions into the shell)

> 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 :(

We don't care about playground :) The people working on the plugins
there (or not) are expected to port their plugins against changes.

Andreas

-- 
Artistic ventures highlighted.  Rob a museum.