GDB/MI (Was: Embedded development)

[Richard Dale]

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:
>
>   debugger/interfaces
>   debugger/ui
>   debugger/backend/gdb_mi
>   debugger/backend/python
>
> 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
> disappear.
>
> 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.

-- Richard