From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11293 invoked by alias); 1 Oct 2002 22:46:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11282 invoked from network); 1 Oct 2002 22:46:23 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 1 Oct 2002 22:46:23 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g91MkDs18058 for ; Tue, 1 Oct 2002 15:46:13 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 1 Oct 2002 15:46:13 -0700 Received: from inghji.apple.com (inghji.apple.com [17.201.22.240]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g91MkCV07841; Tue, 1 Oct 2002 15:46:12 -0700 (PDT) Date: Tue, 01 Oct 2002 15:46:00 -0000 Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gdb-patches@sources.redhat.com To: Andrew Cagney From: Jim Ingham In-Reply-To: <3D9A1D3F.9000104@redhat.com> Message-Id: <70563052-D58F-11D6-BB61-00039379E320@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00023.txt.bz2 Andrew, On Tuesday, October 1, 2002, at 03:10 PM, Andrew Cagney wrote: >> I am a little confused here. One of the design points for the MI is >> the ability to add information to the commands without requiring a >> change in the clients (unless, of course, they wanted to use the new >> information). That should mean that we have set up a situation where >> we can change the mi in substantial ways without having to demand >> that clients rewrite their code to use MI. Shouldn't that mean that >> we can go a long way without having to make incompatible changes? >> And so, imposing the burden on ourselves of not jerking clients >> around all the time would not be such a big deal, and perhaps worth >> the inconvenience it would cause the MI developers? > > Yes, that's the theory. There are always problems though: > > - for some commands, their output is simply bogus. See gdb/672 > > > - var-update syntax is: > ^done,changelist={name="var3",in_scope="true",type_changed="false", > name="var2",in_scope="true",type_changed="false"} > Notice how a single tuple contains several "name" fields :-( JeffJ's > currently comming up with a patch that will preserve the current > behavior. This was putatively bogus, but very easy to parse. It didn't even annoy Rab, when he was first doing this... > > - some parts of the interface were technically flawed. > The breakpoint event stuff that KeithS changed (but not in a backward > compatible way :-(). Not fixing this, further entrenches a flawed > model :-( The only error in that change was not preserving the old > output when mi1 :-( BTW, I haven't seen the actual change Keith is planning here. Will he be sticking the command sequence cookie in the async result? His example didn't show the cookies. Seems to me that reporting command results as an async notification means that we are breaking the tie between the command and its results. It was very nice that I could issue a bunch of commands at some point in the GUI code, then at another place gather up the results, and match them to the initial commands by using the sequence ID's. In the new way of doing things, we have to parse more carefully, and assume that the =breakpoint-create that we just got was the one that came from the -break-insert in the output just above it. It makes the client stream parser have to be more stateful that in the mi0 version, which doesn't seem to me all that good an idea. If the async event has the cookie in it, this will be a little better, though it still means I have a two-step accumulation phase for each command (wait for the async result with the right cookie, then the done with the right cookie...) > > Fixing either of these involves significant change to MI's output, but > it, I think, is for the better. > >> As a client of the MI, this means that in a year or so I have to >> expect to rewrite code that works just fine, because you have deleted >> the support for it from gdb; or carry the burden of maintaining mi1 >> as patches to the gdb sources. And longer term, I can expect to do >> this again next year, unless things "stabilize" before then, which >> they may or may not do. This doesn't sound appetizing to me. >> The MI is a public interface to gdb - and the only really useful one >> we offer to external clients who are not Human beings right now. It >> has been around in gdb, and we have been using it contentedly, for a >> couple of years now. A retroactively stated policy of instability in >> this interface (including the vanishing of useful variants at odd >> intervals) seems very unfair to those who have been using it right >> along, as well as being one which can only slow its uptake in >> general. > > What we're seeing here is the fallout that results from a number of > players creating localized GDBs. GDB developers have started looking > at the underlying problems that Apple and others encountered, and are > trying to fix them. Regretably, per above, this is going to need some > short term change. Just because K&R C kind of sucked, however, doesn't mean that most compiler vendors got to drop support for it... Alternatively, I don't know why the planning model for the changes seems to be - we will change a bit, declare a version, change a bit more, declare another incompatible version and drop the first version, rinse and repeat... In the face of the fact that you most unfortunately have users already, I think you should decide to work out the changes for whatever time it takes for you to come up with a version you are happy with, then stick with that for a product lifecycle-type-timescale, not a patch release timescale. That way people who plan to use this stuff can actually plan their use of it... Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer