asynchronous MI output commands

[Bob Rossi <bob_rossi at cox dot net>]

Hi,

I'm finally getting more time to build the next layer on top of my MI
parser. This layer will look at the parse tree and create a data
structure from it that the front end will find more useful. For
instance, for example,

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.


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.

The first problem that I've run into is determining if an MI output
command is synchronous or asynchronous. I can tell if the MI output
command is asynchronous by looking for, reason="abc", like below,
  47*stopped,reason="end-stepping-range",thread-id="0", ...

I'm assuming reason= has to be the first pair after stopped, or done,.

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", ...

Thanks,
Bob Rossi