From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16284 invoked by alias); 15 Oct 2004 15:40:20 -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 16262 invoked from network); 15 Oct 2004 15:40:17 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 15 Oct 2004 15:40:17 -0000 Received: from white ([68.9.64.121]) by lakermmtao12.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041015154017.YZZ13338.lakermmtao12.cox.net@white>; Fri, 15 Oct 2004 11:40:17 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CIUBl-0006eI-00; Fri, 15 Oct 2004 11:40:17 -0400 Date: Fri, 15 Oct 2004 18:04:00 -0000 From: 'Bob Rossi' To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041015154016.GB25467@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <200410071614.MAA19648@smtp.ott.qnx.com> <20041007224230.GA15177@white> <01c4ad12$Blat.v2.2.2$1796ec80@zahav.net.il> <20041009002901.GB16824@white> <20041013003135.GA22087@white> <01c4b0df$Blat.v2.2.2$e933d3e0@zahav.net.il> <20041013121412.GA22696@white> <01c4b163$Blat.v2.2.2$7d934a60@zahav.net.il> <20041014153720.GA24199@white> <01c4b233$Blat.v2.2.2$873cc700@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4b233$Blat.v2.2.2$873cc700@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00329.txt.bz2 > I was only talking about stable versions, so developmental is not > something we should consider (we've been through this and decided that > it is unsafe to use such versions). Yes, you are correct. > > This information needs to be given to the front end. For > > example, right now GDB supports MI2. However, if a front end understood > > only MI1, then it would be tempted to try MI1 with your approach. > > However, MI1 is unsupported and most likely doesn't work. > > If MI1 is not working and the front end only supports MI1, then this > combination of GDB and front end is not going to work. So I submit > that this case is not interesting: you will try MI1 and things will go > wrong at some point. > > However, ``unsupported'' and ``doesn't work'' are not the same thing. > If we know that a certain version of MI does not work, we should > remove its support from GDB. If we didn't do that, then we have good > reasons to believe that MI1 does in fact work. I think that supported(tested) and unsupported(untested) are two entirely different things. Users should not be responsible for finding bugs in the MI protocol because GDB said that a front end could use a depricated protocol. It's just not fair. Also, above and beyond that, I do not want my front end to work with untested versions of the MI protocol, it would simply make me look bad when things stopped working half way throuh a session. > > It would be > > nice if the front end was capable of understanding that. > > And then do what? print a message "like unsupported GDB version"? Is > this really an interesting case? I consider this a very interesting case. > I thought you were interested in > getting a front end to _work_ with MI; graceful failure is something > different. Can we please solve one problem at a time? Do you agree > that if either (1) the front end supports the latest stable version or > (2) the version before that works reasonably well, then printing only > the latest stable version at startup is good enough? No, I can not agree to that. Again, like I said to andrew, printing the latest stable version simply is common sense. It allows the front end to determine if it can work with the current GDB. It is a different problem than probing GDB to determine what MI versions that it supports. Especially the second case that you have posted makes no sense to me, "the version before works reasonably well". I don't want a reasonably well working verion, I want a version that it tested in the testsuite. > > This seems reasonable. There are 2 down sides that I don't like > > > > * There is no handshaking being done. Average case scenario is starting > > GDB twice to get it into the correct mode. Once to find out the > > supported versions, second to start it in the correct mode. > > I don't see this as a grave problem. > > > * It tells the front end only the minimum information it needs to > > know. (developmental and unsupported interfaces are not printed) > > Again, this probably isn't to important. > > Indeed. > > > What is wrong with the handshaking protocol that I described? > > It is too complicated for the job, IMHO. Can I sum up the solutions we have, because it's obvious that we are not interested in solving the problem the same way. You and I are on the opposite side of each different type of solution that we come up with and this is why it is taking a very long time to reach a middle point. * printing just the latest stable version Is this the version that GDB will start up in if you do -i=mi even if you are using a CVS snapshot and the version has been bumped? This solution is lacking. It only tells the front end the latest stable version of the MI protocol. The front end can only guess what other stable versions are available and I consider this unacceptable. For CVS snapshots, if the above questions is true, then it will always print out the latest stable version and it will be communicating not in that version. This requires a restart no matter what. This does not satisfy the minimum amount of information that I need. * printing all of the tested MI versions. This solution is basically my 'command line switch' solution. This is the minimum information that I need. A front end that wants to work with GDB will need to know every version of the MI protocol that the particular GDB was tested with. However, this solution requires starting GDB twice, which I would not prefer if it was solvable with just starting it once. * creating a handshaking protocol This is the optimal solution since it gives the front end all of the tested MI versions and then allows the front end to select which version GDB should use. This is the solution I prefer. It requires GDB asking the front end for the version, and the other solutions do not require this. It could be as simple as outputting all of the tested MI versions one line at a time and then allowing the front end to select one or it could be more complicated like the grammar that I posted earlier. Thanks, Bob Rossi