This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: asynchronous MI output commands
- From: Alain Magloire <alain at qnx dot com>
- To: gdb at sources dot redhat dot com
- Date: Thu, 11 May 2006 10:58:08 -0400
- Subject: RE: asynchronous MI output commands
> > > For the record, that's basically what I have in KDevelop. There's
> command
> > > queue, and commands are sent to gdb one-at-a-time, and responses come
> > > exactly in the same order. Remembering the last issued command (i.e.
> > > instance of GDBCommand class internal to KDevelop) makes it possible
> to
> > > route the response back to the original command.
> > >
> > > I'm don't quite understand the problems being discussed in this
> thread.
> > > It's
> > > not apparent why one has to know the type of the last command while
> > > parsing, and if so, why remembering the last command is bad idea.
> > >
> > > It's hard to believe that response from MI can be useful without
> knowing
> > > the
> > > last issued command. Say, response from -data-evaluate-expression is
> > > useless if you don't know what part of frontend wants that data --
> > > evaluating expression is used in many use cases. So, you need to
> associate
> > > extra data with commands anyway.
> > >
> >
> > I agree, the example that comes to my mind is "next", "step", "finish",
> > "continue" etc ... To do some optimization front-ends will probably
> need to
> > know the last command issue (for example clearing all the variable state
> in
> > a variable view for "continue").
>
> I see the point, however, how do you know if the user typed continue? I
> allow the user to have access to the console, and by doing so, I can't
> make any assumptions on what GDB is doing.
>
I suppose you could intercept the CLI commands before sending it to GDB
> > Maybe I'm mistaken but I have the impression, looking at the thread,
> some
> > folks are confusing OOB and synchronous response that comes after
> issuing a
> > command.
>
> I'm hopefull not confusing them, but maybe. For synchronous commands, I
> just think it's a little ugly that you need the MI input command to
> determine what an MI output command is.
>
You can certainly parse the MI output without knowing what the input was.
The problem is when you get answer what do you do with it? For example
-data-evaluate-expression may be an action for hovering or to update a tree
viewer etc... Most commands are "synchronous" i.e. an answered to a
question. Usually front ends will have callbacks attach to the MI
question/command.
> For asynchronous commands, there is simply no way to know what you are
> looking at AFAIK. You just have to poke around until your fingers get
> tired. I still need to research this more though.
>
OOB were suppose to be a way for GDB to notify of changes, that did not come
from a user action. Comes to mind hitting a breakpoint, thread creation,
loading of a library, etc...
> Bob Rossi