GDB/MI (Was: Embedded development)
Richard_Dale at tipitina.demon.co.uk
Wed Sep 14 11:03:05 UTC 2005
On Wednesday 14 September 2005 09:23, Vladimir Prus wrote:
> On Wednesday 14 September 2005 11:14, jbb wrote:
> > > How about:
> > > debuggers
> > > debuggers/GDB_shell
> > debuggers/GDB_shell should be debuggers/GDB_CLI, I suspect.
> > > debuggers/GBD_MI
> > > debuggers/ ....
> > >
> > > instead of
> > > languages/c++/debugger
> > > languages/java/debugger
> > I think this is a good suggestion. What says you, Vladimir?
> I'd so as far as suggest this:
> Where there will be some possible debugger interfaces (ValueAccess,
> Breakpoints, MemoryReading) and specific backends will implement whatever
> interfaces they can. The debugger UI will then query supported interfaces
> and enable/disable the specific windows. Say, python debugger backend will
> report that it can't display raw memory, and the memory viewer will
> How does that sound?
Yes, that sounds good to me. If we use Qt4 custom models for the variable
viewer QTreeView, and frame stack widget that should make it easier to
seperate the UI from the debugger code for a specific language.
On the other hand, I think it would be a good idea to get the current gdb
debugger working with MI first, and the code as clean as possible before
trying to re-architect it. I would rather merge a working ruby debugger with
a working gdb debugger, and work out the common architecture for KDevelop4 as
we do that.
More information about the KDevelop-devel