Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Bob Rossi <bob@brasko.net>
To: Konstantin Karganov <kostik@ispras.ru>
Cc: GDB <gdb@sources.redhat.com>
Subject: Re: MI output command error
Date: Thu, 10 Mar 2005 13:06:00 -0000	[thread overview]
Message-ID: <20050310130544.GA13958@white> (raw)
In-Reply-To: <446808079.20050310123642@ispras.ru>

On Thu, Mar 10, 2005 at 12:36:42PM +0300, Konstantin Karganov wrote:
> Hello Bob,
> 
> > There is no way 1 MI input command can result in more than one MI output
> > commands. The front end would probably send 1 command, after it got back
> > the first "(gdb)", and then send another command for the second time.
> > This would cause the front end's buffer to get out of sync with GDB.
> 
> > If anyone think's that this is not a problem, please let me know why.
> I think that is not a problem. Look, in MI specification there are special
> records for status-async-output ("information about the progress of
> slow operation") and notify-async-output ("supplementary information
> that the client should handle"). From these descriptions it is clearly
> possible, that this records can be multiple (say, a progress of a very
> slow operation :) ) plus the result-record for the command.

Yeah, that's what I was thinking. So the '^running' should be replaced
with an '*running' and the extra "(gdb)" should probably be removed. The
problem is finding all the case's that do this and converting them so
that the syntax is still correct. 

> Another similar hint is that there are (oob-record)* in output rule.
> Though it doesn't make several messages now, who knows all the use
> cases and how it will behave in the next versions...

Yeah, the way I'm saying to fix this problem would end up using that
feature.

> For myself, I decided to ignore "(gdb)" strings and wait for the
> appropriate result-record (it will always appear, according to
> grammar), collecting passing async-records at the same time.
> 
> I suppose that the only way to get in line with GDB responses is to
> keep track of message tokens. And implementing the GUI frontend you
> will have to use tokens anyhow.

Yeah, but even using the TOKENS doesn't work. The problem is, whenver I
front end get's a "(gdb)\r\n" it knows that it can send another command.
When you use the tokens with this command, you end up with,

   (gdb) 
   444-exec-continue
   444^running
   (gdb) 
   444*stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
   (gdb) 

This is still incorrect. The front end would have to know that the first
MI output command was not the end of the output from the single MI
input command. In other words, the FE would have to hardcode the fact
that the -exec-contine command may output 2 MI output commands. This
can't be correct, it would be better if the output is changed to,

   (gdb) 
   444-exec-continue
   444*running
   444*stopped,reason="watchpoint-scope",wpnum="2",thread-id="0",frame={addr="0x40039dc9",func="__libc_start_main",args=[],from="/lib/libc.so.6"}
   (gdb) 

That would at least be a start.

Thanks,
Bob Rossi


  reply	other threads:[~2005-03-10 13:06 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09  2:40 Bob Rossi
2005-03-09 23:22 ` Bob Rossi
2005-03-10  9:33   ` Re[2]: " Konstantin Karganov
2005-03-10 13:06     ` Bob Rossi [this message]
2005-03-10 13:43       ` Karganov Konstantin
2005-03-10 14:01         ` Bob Rossi
2005-03-10 14:15           ` Karganov Konstantin
2005-03-10 14:40             ` Bob Rossi
2005-03-10 15:13               ` Karganov Konstantin
2005-03-10 15:52               ` Dave Korn
2005-03-10 16:09                 ` 'Bob Rossi'
2005-03-10 16:13                   ` Daniel Jacobowitz
2005-03-10 17:44                     ` Bob Rossi
2005-03-10 17:52                       ` Daniel Jacobowitz
2005-03-10 20:48                         ` Bob Rossi
2005-03-10 21:10                           ` Daniel Jacobowitz
2005-03-10 21:25                             ` Bob Rossi
2005-03-10 16:23                   ` Dave Korn
2005-03-10 16:34                     ` Daniel Jacobowitz
2005-03-10 16:48                       ` Dave Korn
2005-03-10 17:03                         ` 'Bob Rossi'
2005-03-11 11:32                           ` Re[2]: " Konstantin Karganov
2005-03-11 21:05 Nick Roberts
2005-03-11 21:31 ` Daniel Jacobowitz
2005-03-11 21:36   ` Bob Rossi
2005-03-11 21:39     ` Daniel Jacobowitz
2005-03-11 21:52   ` Nick Roberts
2005-03-12 10:23     ` Eli Zaretskii
2005-03-13  9:36       ` Nick Roberts
2005-03-13 15:40         ` Daniel Jacobowitz
2005-03-13 20:22           ` Nick Roberts
2005-03-13 20:25             ` Daniel Jacobowitz
2005-03-13 23:33               ` Nick Roberts
2005-03-13 23:38                 ` Daniel Jacobowitz
2005-03-13 19:41         ` Eli Zaretskii
2005-03-14  7:16           ` Peter D HUERTER
     [not found] <1110656346.18541.ezmlm@sources.redhat.com>
2005-03-14 19:11 ` Jim Ingham

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=20050310130544.GA13958@white \
    --to=bob@brasko.net \
    --cc=gdb@sources.redhat.com \
    --cc=kostik@ispras.ru \
    /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