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 12:52:49PM -0400, Daniel Jacobowitz wrote:
> On Sat, May 06, 2006 at 12:40:31PM -0400, Bob Rossi wrote:
> > Each of the lines beggining with ~ are an 
> >   out-of-band-record => stream-record.
> > There is no out-of-band-record => async-record.
> > 
> > Certainly having an out-of-band-record => stream-record does not make an
> > MI output command asynchronous. Or does it?
> 
> `OUTPUT ==>'
>      `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL'
> 
> It's an OOB record, followed by a prompt.  It's not the direct output of
> any command.

OK, we are going in circles. I currently have a goal of determining if a
MI output is synchronous or asynchronous. So far, I think we have agreed
that an asynchronous command from GDB is a command that is sent from GDB
that was not a response from a command sent to GDB from the FE.

GDB uses the term asynchronous all over the place in the manual, even if
the asynchronous part is faked. I was under the impression that every 
asynchronous MI output command would have to funnel through the
  'async-record ==>' part of the grammar. You mentioned I could look for
*stopped, which is down stream of async-record.

So, either this is a special case, or we could put into this case the
reason GDB is sending data to the front end, which I think would be
appropriate. In fact something like,

~"GNU gdb 6.1-debian\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n"
~"welcome to change it and/or distribute copies of it under certain conditions.\n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
~"This GDB was configured as \"i386-linux\"..."
~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
~"\n"
*stream-update
(gdb)

and change

async-class ==>
    "stopped" | others (where others will be added depending on the needs--this is still in development).

to

async-class ==>
    "stopped" | "stream-update" | others ...

I know this seems rather pedantic, and I'm not trying to cause problems
where there are none, however, this case just doesn't make sense. Of
course I could just consider it synchronous and everything will just
work fine, however, I'd like to make this as pure as possible.
  
> > The code I wrote to determine if an MI output command is asynchronous
> > checks to see if there is an out-of-band-record=>async-record in the
> > parse tree. If there is, the command is asynchronous, otherwise it's
> > not. Do you disagree with this?
> 
> "MI output command" doesn't mean anything to me.  It's an MI output
> record, and it isn't in response to a command.

Sorry, I was using the term "MI output command" to mean a single
response from GDB to the FE. In the grammar that would be 'output ==>'.

> I still don't understand the question - the point of categorizing
> messages in this way.

I was hoping to tell the front end if the command was asynchronous or
not. There is a use in knowing if the command is asynchronous or not.
First of, if the command is asynchronous then I don't have to probe the
parse tree to determine if it represents the results to say,
-file-list-exec-source-file or some other commands. I know when building
the ADT for the FE that it's an asynchronous command, and that limits
the amount of probing in the parse tree I have to do.

Ideally, I wouldn't have to prove at all, GDB should probably state in
the MI output what kind of command it's responding to. For instance, 
instead of

-file-list-exec-source-file
^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
(gdb)

It could output

-file-list-exec-source-file
%-file-list-exec-source-file
^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
(gdb)

Anyways, I'm going over board for now, but I hope you can see the reason I'm
asking for this functionality in the initial response from GDB.

Thanks,
Bob Rossi


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