From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31530 invoked by alias); 25 Sep 2004 01:05:22 -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 31511 invoked from network); 25 Sep 2004 01:05:20 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 25 Sep 2004 01:05:20 -0000 Received: from white ([68.9.64.121]) by lakermmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20040925010519.YBBE1590.lakermmtao01.cox.net@white>; Fri, 24 Sep 2004 21:05:19 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CB103-0000t8-00; Fri, 24 Sep 2004 21:05:19 -0400 Date: Sat, 25 Sep 2004 01:05:00 -0000 From: Bob Rossi To: Jim Ingham Cc: gdb@sources.redhat.com Subject: Re: MI rules Message-ID: <20040925010519.GB3379@white> Mail-Followup-To: Jim Ingham , gdb@sources.redhat.com References: <1095954341.19418.ezmlm@sources.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2004-09/txt/msg00229.txt.bz2 On Thu, Sep 23, 2004 at 11:23:18AM -0700, Jim Ingham wrote: > Sorry for being so late in chiming in, but I guess I am not clear on > exactly what the problem is here. Don't be, thanks for responding. > Xcode uses the command tokens through-out, so it always is able to > match up the command & it's result. We had to do some work to make > sure that if a command like -exec-run gets the target going, and you > come along and issue another command, you still get a running & a > stopped that have the correct numbers. > > But I don't think this would be a real problem for the FSF gdb right > now, since there are very few real (any)asynchronous targets in actual > use. If there are, you can look at what we had to change to get this > working. It was tricky IIRC, but not that bad. OK, I understand that it is possible to use the tokens to be able to tell what MI output commands is coming out of GDB when it is issuing syncronous commands. > > Anyway, you almost always will need more information than just "what > was the name of the MI command that I issued", right? You can issue a > whole bunch of "-var-create" commands, for instance, and just knowing > that you issued -var-create isn't going to help you at all. You need > to tie each one to the particular variable the varobj was representing. > So issuing & keeping track of the tokens is pretty much mandatory > anyway, and once you are doing that, you pretty much know how to > interpreter each return value. This is a good point. I haven't got this far in my implementation. > Other that that, there are the asynchronous notifications that come > from gdb when something interesting happens, but those should already > all have some unique tag after the "=" that tells you what the data is. > > I don't have any big problem with adding the command name after the > command token or something similar, but I don't see that it really adds > much in practical terms. It also looks to me like this will be a > backwards-incompatible change to the mi, no? If so you should bump the > MI version if you add this. Please take a look at http://sources.redhat.com/ml/gdb/2004-09/msg00200.html I have summarized the two issues better there. One of the issues is more important, and that deals with MI outuput commands and backwards compatibility. Finally, I personally think that every MI output command should self document what type of command it is. This tells the front end easily what kind of MI output command walker should be used to understand the data. I understand the front end could use the tokens to figure it out, but I think it's something that should be self evident from having the MI output command. Finally, for instances like -var-create I would suggest adding a new field to the -var-create that gives it a unique id ( like tokens ). Then, whenever a -var- response from GDB it should tell you that it is issuing a -var-create response and it is tied to the unique id. That way the front end can match it up. Personally, I think all of these things can be done easily at the GDB level and can avoid unnecessary confusion in the front ends. Does it sound unreasonable for a MI output command, either syncronous or asyncronous to say what kind of command it is? Input is greatly appreciated since I've already made it passed the parsing stage of the MI output commands and want to start interpretting the data. Basically, I hope that the bison parser that I have will be usable by other front end developers one day. I also think that for each MI output command that they get, they should be able to understand how to interpret the data, without having to do lookups to figure out what type of command it is, or wihtout having to look at the data to figure out what kind of command it is. Thanks, Bob Rossi