asynchronous MI output commands

[Nick Roberts <nickrob at snap dot net dot nz>]

 > Starting with this MI output command, 
 >   -file-list-exec-source-file
 >   ^done,line="1",file="main.c",fullname="/home/bob/cvs/gdbmi/builddir/src/main.c"
 >   (gdb)
 > I get back a parse tree, and from that, I'll define something like,
 > 
 > struct file_list_exec_source_file
 > {
 >   int line;
 >   char *filename;
 >   char *fullname;
 > };
 > 
 > with the correct values filled in.
 
Presumably Emacs would need the parser to output Lisp.

 > So far, I've created the parse tree code, and a small TCL extension
 > which allows me to grab all of the MI output commands from the
 > testsuite. I've written all of these output commands to a temporary file,
 > which I use for input to my drive program.

Emacs has a Lisp interpreter, of course, so it could take Lisp output from a
parser and act on it.  AFAIK C isn't interpreted, so how does your program use
it?

 > My question is, should we say it's a bug on GDB's part if reason= isn't
 > the first pair returned for an asynchronous MI output command? Should I
 > assume if the MI output command has reason= anywhere in it that it's an
 > asynchronous command? or should we add an extra piece of information into 
 > the MI output command stating that the command is asynchronous. 
 > For instance,
 > 
 >   47*stopped,asynchronous,reason="end-stepping-range",thread-id="0", ...

I think you should assume that if it has *stopped, the output is asynchronous.
Of course, as we've said before, currently all the output (except possibly for
a remote target) is synchronous in reality.

-- 
Nick                                           http://www.inet.net.nz/~nickrob