Re: asynchronous MI output commands

[Bob Rossi <bob_rossi at cox dot net>]

On Sat, May 06, 2006 at 03:27:05PM +1200, Nick Roberts wrote:
>  > 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.

Sounds great to me.

>  > 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?

I probably wasn't clear here. I have the MI parser, which just creates
the parse tree. I wrote a small TCL extension that is capable of taking
an MI output command and writing it to a file if the parse passed.

            set parse_result [gdbmi_parse $expect_out(2,string)]
            if [string match "syntax error" $parse_result] then {
              puts "MI_OUTPUT_COMMAND($expect_out(2,string))"
              fail "Syntax check of MI Output Command failed"
            } else {
               puts -nonewline $fileId $expect_out(2,string)
            }
So, after I run the testsuite, I have all the valid MI output commands
from the test suite in /tmp/data.mi.

Then, I have a driver program which reads a file that has MI
descriptions in it (/tmp/data.mi) and parses each of them. I am know
starting to work on the part that takes the parse tree and provides a
semantically correct data structure for the front end to use. The only
reason I wrote the tcl extension is to validate the test suite. It
turned out I was also easily able to gather a bunch of MI output
commands for testing as well.

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

OK, I will take your suggestion, as well as Daniel's on this point.
Thanks for the help.

Bob Rossi