From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5163 invoked by alias); 29 Sep 2004 16:13:49 -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 4976 invoked from network); 29 Sep 2004 16:13:45 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 29 Sep 2004 16:13:45 -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 i8TGHVeL023577 for ; Wed, 29 Sep 2004 09:17:31 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Wed, 29 Sep 2004 09:13:43 -0700 Received: from [17.201.22.245] (inghji6.apple.com [17.201.22.245]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i8TGDf5d019286 for ; Wed, 29 Sep 2004 09:13:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040929025959.GA357@white> References: <1095954341.19418.ezmlm@sources.redhat.com> <20040925010519.GB3379@white> <4E6C7AD8-0F25-11D9-AD7A-000D932CB92C@apple.com> <20040925201242.GA4133@white> <1AB1A5F6-10AC-11D9-8F3A-000A958F4C44@apple.com> <20040929025959.GA357@white> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <879F6C54-1232-11D9-A48C-00039379E320@apple.com> Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI rules Date: Wed, 29 Sep 2004 16:13:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2004-09/txt/msg00256.txt.bz2 Bob, First, I think parts of the discussion are unclear because you are a little lax on terminology. What you are calling asynchronous COMMANDS are really asynchronous NOTIFICATIONS. They aren't the result of a command, but something that happens in gdb that gdb decides it ought to tell you about. There are actually different mechanisms to emit them in gdb, so they are clearly separated in the code. And yes, ALL asynchronous notifications need to be tagged. I haven't played around with TOT without our modifications, so I can't actually tell you what the state is there, but if this isn't the case it certainly ought to be. I would be surprised if they weren't, but... About incompatible changes. I see the need to have a stable version of the MI so that you can deliver a front end that will work with some reasonable range of gdb's. OTOH, putting a whole lot of effort into making your front end work with every possible variant of the development versions of the MI seems to me like a misdirection of our limited resources. The current state falls short of your needs right now because you need to use the development version only, and until that is stable, you are in a bind. But over designing for a side effect of the software not being all the way done is not as good a use of resources as actually getting a stable version that has what you need... The thing I think we really need to work on (besides tagging notifications if there is any place they aren't tagged) is making the command INPUT more robust. The output is already pretty good, there is seldom a need to remove fields, and adding fields is done in a way that the client can handle. But the command input is not similarly self-labeling, and thus much more fragile. Jim On Sep 28, 2004, at 7:59 PM, Bob Rossi wrote: > I have one quick note. I would prefer to get some cooperation with the > MI maintainers. I seriously need this cooperation in order to get > anything done with CGDB. Also, I consider the work I am doing necessary > for any front end developer to be able to write a reasonable front end > without having to heavily patch a version of GDB they distribute with. > > If you consider my goal worthy, please at least respond with some > reasonable criticism so that these issues can be resolved. I feel that > in > many ways my views on the MI are mostly ignored by the MI maintainers. > I would like to improve GDB in the areas that seem relevant to front > end > developers and am assuming that you all have the same goal. So > hopefully these issues and the ones in the future can be resolved > within > a reasonable amount of time. > > > On Mon, Sep 27, 2004 at 10:38:55AM -0700, Jim Ingham wrote: >> >> 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=""] > > OK, so this is exactly what I'm talking about. There needs to be a > label > for asynchronous commands. I guess it's not necessary for synchronous > commands but I think it could be useful to have there anyways and it > would be trivial to add. > >> 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. > > I think this also needs to be done in the mainline GDB and I would > prefer the synchronous commands to get a tag also. Do you agree with > the > asynchronous part at least? > >>> 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. > > OK, so understood. > > Commands that add a field will definatly work because the front end > ignores them. Commands that loose a field will probably cause a major > problem and will be incompatible with the front end. > > What about when a command changes completly because of a version bump? > What about when the commands changes (like N:M breakpoints) and the > version is not bumped yet because you have a snapshot of GDB? > > I need these case's to work because I am not bundled with GDB. > > So again, I'm asking everyone, > > 1. Can the mainline version get tagged asyncronous commands at the > least? > I would prefer every command to have a tag. > > 2. Can there be a discussion about backwards compatibility with MI > output commands. This involves several issues I can think of. > 1. removing fields from an MI output command > 2. changing the output of an MI output command > 3. Making the commands themselves be backwards compatible even > between major releases. This essentially makes the MI output version > useless. > > Thanks, > Bob Rossi > -- Jim Ingham jingham@apple.com Developer Tools Apple Computer