From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2188 invoked by alias); 25 Sep 2004 19:01:39 -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 2176 invoked from network); 25 Sep 2004 19:01:37 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 25 Sep 2004 19:01:37 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i8PJ5D2h022346 for ; Sat, 25 Sep 2004 12:05:13 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Sat, 25 Sep 2004 12:01:36 -0700 Received: from [17.112.105.211] ([17.112.105.211]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i8PJ1VPv003088; Sat, 25 Sep 2004 12:01:33 -0700 (PDT) In-Reply-To: <20040925010519.GB3379@white> References: <1095954341.19418.ezmlm@sources.redhat.com> <20040925010519.GB3379@white> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4E6C7AD8-0F25-11D9-AD7A-000D932CB92C@apple.com> Content-Transfer-Encoding: 7bit Cc: gdb@sources.redhat.com From: Jim Ingham Subject: Re: MI rules Date: Sat, 25 Sep 2004 19:01:00 -0000 To: Bob Rossi X-SW-Source: 2004-09/txt/msg00231.txt.bz2 I have no strong opposition to this, I just don't see the point. I think any sane implementation of the MI driver is going to want to use the command tokens to keep track of the commands that are issued, to make sure something hasn't been dropped on the floor, do good error reporting - "Which command was it that went wrong..." etc. And once you are doing that, you always know exactly what command you issued and what you got back. OTOH, adding some kind of command identifier to the return is mostly pretty easy, you can just hook into the mechanism that issues the command token. Note that this code is not quite as trivial as it seems - and I think the FSF version doesn't work correctly in all cases - particularly with async targets, and when you allow things like breakpoint commands. For instance if you allow breakpoint commands that can cause the target to run (like a "continue" in a breakpoint command) for an asynchronous target, you will get a stopped message, but then you have to issue another ^running and maybe some indication of what happened to the GUI, and all these are bound to the original -exec-continue or whatever got the target going. I fixed a bunch of this stuff on our side, and I don't remember seeing similar work go on on the FSF side (though I may have missed it). Sadly that sits on top of a pile of other changes to support asynchronous targets that only exist on our side... But you should at least be aware that this is not entirely straight-forward... OTOH, if you ever get to your goal of having a data-driven validator for the command returns, I can see it might be useful. A few specific comments below... On Sep 24, 2004, at 6:05 PM, Bob Rossi wrote: > 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. This has just never come up in the 4 years I have been supporting the Xcode guys. There are LOTS of things they want from us, some of which we have provided, some not. But this one has never seemed a problem. > > 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. This IS what the command tokens are for. I don't at all think it is a good idea to replicate this mechanism. As it stands it works just fine, and I don't see any point in doing it twice, that just introduces more chances for bugs. And you certainly want a general mechanism to tag every command you issue, so you can't replace it with a command specific mechanism. > > 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? Not unreasonable, just more code that we have to maintain for what seems to me like marginal benefit. Tracking the tokens and getting them to be right is not quite as trivial as it seems, and this just adds a little more weight to that mechanism. But given that that already works, if you can hook onto that you can probably do it without adding to much of a maintenance burden. It will probably also be an incompatible change, so you will have to mark it as such. > > 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 > Jim _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb