Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Bob Rossi <bob_rossi@cox.net>
To: gdb@sourceware.org
Subject: Re: asynchronous MI output commands
Date: Sun, 07 May 2006 00:44:00 -0000	[thread overview]
Message-ID: <20060506194618.GL25114@brasko.net> (raw)
In-Reply-To: <20060506165249.GA25972@nevyn.them.org>

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


  reply	other threads:[~2006-05-06 19:45 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-06  1:26 Bob Rossi
2006-05-06  1:59 ` Daniel Jacobowitz
2006-05-06  2:48   ` Bob Rossi
2006-05-06  3:37     ` Nick Roberts
2006-05-06 15:20       ` Bob Rossi
2006-05-06  4:06     ` Daniel Jacobowitz
2006-05-06  4:05       ` Daniel Jacobowitz
2006-05-06 11:53       ` Bob Rossi
2006-05-06 12:06         ` Bob Rossi
2006-05-06  3:14   ` Bob Rossi
2006-05-06  4:04     ` Nick Roberts
2006-05-06 11:49       ` Daniel Jacobowitz
2006-05-06 11:50         ` Bob Rossi
2006-05-06 16:52           ` Daniel Jacobowitz
2006-05-06 19:45             ` Bob Rossi
2006-05-06 20:37               ` Daniel Jacobowitz
2006-05-07  0:44                 ` Bob Rossi [this message]
2006-05-07 20:35                   ` Daniel Jacobowitz
2006-05-07 20:42                     ` Bob Rossi
2006-05-07 22:01                       ` Daniel Jacobowitz
2006-05-08  1:22                         ` Bob Rossi
2006-05-08  2:03                           ` Daniel Jacobowitz
2006-05-09 21:48                             ` Bob Rossi
2006-05-08  6:38                           ` Nick Roberts
2006-05-08 11:28                             ` Bob Rossi
2006-05-08  1:26                         ` Bob Rossi
2006-05-06 11:51       ` Bob Rossi
2006-05-06  3:27 ` Nick Roberts
2006-05-06 16:40   ` Bob Rossi
     [not found] <1147034156.28828.ezmlm@sourceware.org>
2006-05-07 21:27 ` Bjarke Viksoe
2006-05-07 21:41   ` Daniel Jacobowitz
2006-05-10 12:43     ` Vladimir Prus
2006-05-07 22:30 Bjarke Viksoe
2006-05-07 22:50 ` Daniel Jacobowitz
2006-05-08  0:36   ` Bjarke Viksoe
2006-05-08  1:52     ` Daniel Jacobowitz
2006-05-09  9:46 Alain Magloire
2006-05-10 22:15 Alain Magloire
2006-05-11  3:41 ` Bob Rossi
2006-05-11  8:58   ` Vladimir Prus
2006-05-11 10:48     ` Bob Rossi
2006-05-11 10:52       ` Vladimir Prus
2006-05-11 11:14         ` Bob Rossi
2006-05-11 12:50           ` Vladimir Prus
2006-05-11 14:50             ` Bob Rossi
2006-05-11 15:02 Alain Magloire
2006-05-11 15:42 ` Bob Rossi
2006-05-11 16:40   ` Jim Ingham
2006-05-11 17:03     ` Daniel Jacobowitz
2006-05-11 17:35       ` Jim Ingham
2006-05-11 19:24     ` Bob Rossi
2006-05-11 19:25       ` Jim Ingham
2006-05-12  0:19 Alain Magloire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060506194618.GL25114@brasko.net \
    --to=bob_rossi@cox.net \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox