GDB/MI (Was: Embedded development)

[Vladimir Prus]

On Wednesday 14 September 2005 11:41, jbb wrote:

> > 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?
>
> Sigh - I've been too long away from this type of code.
>
> It sounds.... flexible and good.
> It also sounds like a rewrite :-)

Noway ;-) In fact, current gdbcontroller.h uses signals and slots for 
everything, which are not tied to C++ typesystem, so the only real change 
would be adding

   enum Capability { ValueAccess, MemoryAccess, Breakpoints, ...... };
   virtual bool hasCapability(Capability capability);

to DBGController and making the debugger disable views that are not supported. 
Then, adding another debugger backend, ironing out any issues. Everything 
else is just moving files around :-)

- Volodya