GDB/MI (Was: Embedded development)

[jbb]

On Wednesday 14 September 2005 19:34, Vladimir Prus wrote:
> On Wednesday 14 September 2005 11:25, jbb wrote:
> > On Wednesday 14 September 2005 05:07, Alexander Dymo wrote:
> > > On Tuesday 13 September 2005 11:36, Roberto Raggi wrote:
> > > > 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 :-)
> > >
> > > Yeah, I suck a lot :)
> > >
> > > > maybe we can use this experience to re*design/develop* it
> > > > Alexander?, Vladimir? John? :-)
> > >
> > > I did it once, I can do it again. I can write a simple mi
> > > implementation again for KDevelop4. Unfortunately, I will not do that
> > > in September, I have too much work :( (only 3 working days at
> > > university, but all other days are spent to prepare for lectures/etc.)
> >
> > Perhaps MI's time has finally come. The parser should be easier than our
> > current one but I'm not sure it supports all the commands we need. But is
> > there an MI wrapper for CLI commands?
>
> What do you mean? Is it possible to send CLI commands in MI mode? Yes, just
> writing them will work. And for experiments with MI, we can use
>
>    interpreter mi "<mi-command>"
>
> in TUI mode, which will allow to play with MI without abrupt switch to MI.
> One thing, though: if all commands to gdb are in MI, then there's no point
> in showing them in the "gdb" window -- the responses from most MI commands
> are not for user.

I'd go with switching to MI and then sending CLI commands if there isn't an 
equivalent MI command. I've never liked the guessing we have to do to see if 
gdb has stopped or not. It's very ugly. Being in MI mode should remove all 
that, but being in CLI mode and sending an "experimental" MI command would 
really get you any further forward. However, I'm not the one whos doing 
this :-) so you can ignore my comments :-)

>
> This reminds me of:
>
>    http://bugs.kde.org/show_bug.cgi?id=81277
>
> Maybe, we indeed should use GDB window only to show output of user
> commands, and filter out everything that frontend sends itself?

That filter idea is good. I think ther are situations where you want to show 
all the interaction with gdb but not all the time. (or instance, when I'm 
curious as to how you actually control gdb).

jbb