This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: asynchronous MI output commands
On Thursday 11 May 2006 06:37, Bob Rossi wrote:
> > > 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.
The "continue" command always produces
*stopped
response and that's mostly enough for frontend.
>
> > 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.
What do you mean by "determine what an MI output command is"? You certainly
can parse the response into DOM-like tree without knowing the output command.
If you want to create C data structures for each response, then yes, you'd
need to know the exact type of the last command. But then, I'm not sure why
you want to use C data structures. In KDevelop, the DOM is fully dynamic and
that works just fine, for example:
const GDBMI::Value& children = r["children"];
for (unsigned i = 0; i < children.size(); ++i)
{
QString exp = children[i]["exp"].literal();
If you have specific structures for each response this won't be very much
simpler.
> For asynchronous commands, there is simply no way to know what you are
> looking at AFAIK.
What exactly do you want to know that's not obtained from parse tree?
- Volodya