GDB/MI (Was: Embedded development)
ghost at cs.msu.su
Wed Sep 14 11:23:05 UTC 2005
On Wednesday 14 September 2005 11:57, Richard Dale wrote:
> > 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.
As a side question: say I want to completely change visualization of a certain
item in frame view. Instead of text, I want a combobox saying "More frames
follows" and allowing to select a number of additional frames to show.
How do I do that with Qt4 views architecture? It looks like I'd need
QListView::setItemDelegate and that "special" item, which somewhat breaks
separation. I would prefer it if QAbstractItemModel could specify specifing
> 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.
Let's see. First of all, I need to finish some work on current debugger
(memory and register views). That goes to KDevelop 3.4 branch.
Then I'd look at bugs -- some really better fixed. And then, I'll start
playing with MI. That all is going to happen on KDevelop 3.4 branch,
I don't know yet when I'll port this to Qt4.
More information about the KDevelop-devel