This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
asynchronous MI output commands
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Bob Rossi <bob_rossi at cox dot net>
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 6 May 2006 15:27:05 +1200
- Subject: asynchronous MI output commands
- References: <20060506012706.GA25114@brasko.net>
> 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