GDB/MI (Was: Embedded development)
ghost at cs.msu.su
Tue Sep 13 10:52:02 UTC 2005
> In KDevelop4 I would like to split the GUI from the GDB-support. The idea
> is to reuse the GUI to integrate different debuggers. As I said before I
> want to avoid code duplication and cut&paste int KDevelop4.
Yes, me too. But in fact, the only code duplication we have is with Ruby,
and it will be hard to merge both debuggers. And I'm still sceptical of the
idea that we can implement, say, Python debugger, using the same interface.
It should be also noted that current debugger code has some attempt at
separating debugger backend -- there's abstract class DBGController that's
supposed to encapsulate all debugger operations. But at the moment,
GDBController is the only implementation. Do you have some specific
"different debuggers" in mind?
> About the GDB-support. I know GDB/MI is incomplete and we need to mix
> GDB/shell commands and GDB/MI commands, but to me it sounds like the
> _right_ (tm) tecnology to use. What do you think about GDB/MI and integrate
> it in KDevelop?
I did comment on that in my reply to Alexander Dymo recently. The current
state of MI is not very promising. On the other hand, it offers some
advantages, like proper error reporting (In TUI, error messages go to stderr,
so it's not easy to understand which command which error message relates to).
I think I'll try to use MI for one or two commands (say, getting variable
value and memory content) and see how it goes.
> A couple of years ago I wrote a simple GDB/MI analyzer and Alexander
> implemented a simple debugger with it. Unfortunatly he deleted the
> Debugger :-) maybe we can use this experience to re*design/develop* it
> Alexander?, Vladimir? John? :-)
There's MI parser by Bob Rossi (the person doing lots of work on MI in gdb),
OTOH, it's C interface. Where can I get your parser?
More information about the KDevelop-devel