From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14889 invoked by alias); 10 Mar 2005 13:06:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14425 invoked from network); 10 Mar 2005 13:05:47 -0000 Received: from unknown (HELO lakermmtao05.cox.net) (68.230.240.34) by sourceware.org with SMTP; 10 Mar 2005 13:05:47 -0000 Received: from white ([68.9.64.121]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050310130541.JRSR3789.lakermmtao05.cox.net@white>; Thu, 10 Mar 2005 08:05:41 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1D9NMG-0003dT-00; Thu, 10 Mar 2005 08:05:44 -0500 Date: Thu, 10 Mar 2005 13:06:00 -0000 From: Bob Rossi To: Konstantin Karganov Cc: GDB Subject: Re: MI output command error Message-ID: <20050310130544.GA13958@white> Mail-Followup-To: Konstantin Karganov , GDB References: <20050309023957.GB10866@white> <20050309232239.GB12792@white> <446808079.20050310123642@ispras.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <446808079.20050310123642@ispras.ru> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00099.txt.bz2 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