This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: asynchronous MI output commands


On Sat, May 06, 2006 at 08:45:18PM -0400, Bob Rossi wrote:
> OK, with that information, I see it is impossible to tell just from 
> looking at the MI output, to determine if the command is synchronous 
> or not. Look below for a solution to this problem for me.

What?  ^done is a synchronous response, *stopped is an asynchronous
response.  There's not really any way of knowing whether a command
might produce later asynchronous output.

[Here we run into the limits of the current, mostly synchronous
implementation.]

> Hmmm. That's interesting, I was hoping to not need to know what the
> input command was in order to parse and build an ADT for the output. In
> general, I think it would be appropriate if the MI output described
> itself well enough that no other information was needed to understand
> it, including the MI intput command.

What do you mean, in this context, by an ADT (and what does it mean to
you)?  And what information do you want to represent in your parse
result?  I think I need to understand what you want to get out of this
data a little better.

It seems to me that most of the work of an MI parser is in converting
the RESULT rule to some more useful tree-like structure.  You don't
need to know what the data is to do that.  If you want to create
individual response structure types for each supported MI command, then
you ought to know what command is being answered (see my mail a moment
ago for why), and be able to convert the _abstract_ tree into an
appropriate _concrete_ structure.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]