From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22061 invoked by alias); 27 Sep 2004 17:39:02 -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 21897 invoked from network); 27 Sep 2004 17:38:59 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 27 Sep 2004 17:38:59 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i8RHgfeJ021753 for ; Mon, 27 Sep 2004 10:42:41 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Mon, 27 Sep 2004 10:38:59 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i8RHcvR1017926; Mon, 27 Sep 2004 10:38:57 -0700 (PDT) In-Reply-To: <20040925201242.GA4133@white> References: <1095954341.19418.ezmlm@sources.redhat.com> <20040925010519.GB3379@white> <4E6C7AD8-0F25-11D9-AD7A-000D932CB92C@apple.com> <20040925201242.GA4133@white> Mime-Version: 1.0 (Apple Message framework v675) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1AB1A5F6-10AC-11D9-8F3A-000A958F4C44@apple.com> Cc: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI rules Date: Mon, 27 Sep 2004 17:39:00 -0000 To: Bob Rossi X-SW-Source: 2004-09/txt/msg00238.txt.bz2 On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote: > On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote: >> I have no strong opposition to this, I just don't see the point. >> > > Jim, I appreciate the time you have spent thinking about this issue for > me. I value the input from someone who has been working with MI for > quite some time. I have several questions for you, > > 1. How do you figure out what type of asynchronous MI output command > you just received is? There are two things here - there is asynchronous output from an MI command, like stopped, running, etc. We added "running breakpoint command message so you can tell that it might start up again..." This sort of thing - usually from running. They are always linked to the original command by preserving the command token. So that's easy. Then there is true asynchronous communications from the inferior - unsolicited messages like shared library notification, or the fact that a user command ("interpreter-exec") caused a breakpoint to be set, the thread or the frame to be changed, etc... These are all dealt with just as you suggest for commands - they have a tag at the beginning specifying the kind of event. So for instance, when a shared library gets loaded, we get: =shlibs-added,shlib-info= [num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld- addr="0x83d50000",reason="dyld",requested- state="?",state="N",path="",description="/Developer/Applications/ Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/ PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""] We are also a bit behind the times, and still use the HOOKS - haven't got around to absorbing Andrew's observers yet... So we also get stuff like: -interpreter-exec console "break captured_main" Breakpoint 3 at 0x2960: file ../../gdb/src/gdb/main.c, line 122. ^done,MI_HOOK_RESULT={HOOK_TYPE="breakpoint_create",bkpt= {number="3",type="breakpoint",disp="keep",enabled="y",addr="0x00002960", func="captured_main",file="../../gdb/src/gdb/ main.c",line="122",times="0"}} Again, the truely unsolicited stuff (in this case the breakpoint creation notification) is all tagged so the UI can figure out what is going on. > > 2. How do you deal with your MI front end dealing with snapshots of > GDB? For example, it has new asynchronous commands, but the MI > version > hasn't been bumped yet. There are two kinds of additions, right? Command return fields, and async notifications. In Xcode, the parser parses everything, and then any command return fields or async notifications that it doesn't understand, it ignores. That's pretty much how the MI was designed, so that the MI can freely ADD notifications & command return fields, and the UI can just ignore them. The fields are identified by field name, and the notifications by their notification name. If we were to take away a field the UI wanted, then Xcode would probably yell at us. But we don't generally do that, we just add stuff. And of course you can't change the meaning of command arguments - that's why Jason has been on the rampage about positional commands in the mi - it would be MUCH more robust if they were all of the "command -switch value -switch value" type, then they would share the robustness of the mi output. > > > Finally, I want to make an analogy and I would like for someone to tell > me where my thinking went wrong. > > GDB and a leaf collecting hobbyist are best friends. For some odd > reason, > GDB has tons of different kinds of leafs and the hobbyist is just > getting his collection started. The hobbyist, named Foo, often asks > GDB for a particular kind of leaf, knowing that GDB has it. Since > GDB > is willing to get rid of some of his collection, he sends to Foo the > leaf every time. Sometimes, when GDB finds an extra leaf, he sends > it to > Foo, even though Foo didn't ask for it. The only problem is, Foo > can not > figure out what kind of leaf he got, since there are several others > that look almost exactly like it. So Foo spends a large portion of > the time guessing what kind of leaf he was just given, even though > GDB could have just put on the envelope the type of leaf that it > was. Foo can not understand why GDB is so mysterious about the leafs > he hands out. The end. > > hehe, anyways, I'm interested in hearing how you solve the top two > problems. We have never really had problems like this. We send lots of notifications that Xcode ignores. Of course, we might be sending one that it really OUGHT to take into account, but if that's true, just identifying the notification wouldn't help, it would have to know what to do about it. This sort of reactive logic would be pretty hard to run in a data-driven way, so it's probably best to just ignore them, get the bug report that something went wrong & Xcode didn't notice it, and then go fix Xcode for the next release. Jim