From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32128 invoked by alias); 23 Sep 2004 18:23:37 -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 31567 invoked from network); 23 Sep 2004 18:23:08 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 23 Sep 2004 18:23:08 -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 i8NIQdHd028356 for ; Thu, 23 Sep 2004 11:26:39 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Thu, 23 Sep 2004 11:23:07 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id i8NIN5Fq026827 for ; Thu, 23 Sep 2004 11:23:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v674) In-Reply-To: <1095954341.19418.ezmlm@sources.redhat.com> References: <1095954341.19418.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI rules Date: Thu, 23 Sep 2004 18:23:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2004-09/txt/msg00205.txt.bz2 Sorry for being so late in chiming in, but I guess I am not clear on exactly what the problem is here. 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. 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. 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. Jim On Sep 23, 2004, at 8:45 AM, gdb-digest-help@sources.redhat.com wrote: > > > On Wed, Sep 22, 2004 at 12:18:06PM -0400, Bob Rossi wrote: > >> I wasn't being critical at all. Personally, I don't like the fact that >> Eclipse use's a hybrid approach to getting data out of GDB. I have not >> even started adding MI to CGDB because I've been working on GDB, >> bringing it up to the standards I need to get CGDB fully usable by >> only >> using MI. If others would follow this approach, I'm sure my life would >> have been a lot easier, and CGDB would have been far more along. > > For what it's worth, Xcode (the IDE on MacOS X) uses something like > one non-MI command these days ("tty"). It's true that we've done a > lot of work on the MI side of gdb, but an example of an MI-only > (well, nearly so - there's no bonus points for having 100% MI usage > so we have that one command there) exists and has been shipping for > at least a few years now. NB Xcode is gratis free, but not libre free, > i.e. not free software. > > J