From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9160 invoked by alias); 5 Oct 2004 06:59:21 -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 9151 invoked from network); 5 Oct 2004 06:59:20 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 5 Oct 2004 06:59:20 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i956xJpd025120 for ; Tue, 5 Oct 2004 08:59:19 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Tue, 05 Oct 2004 08:58:37 +0200 Message-Id: <5.2.0.9.1.20041005085052.01ce8e18@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Tue, 05 Oct 2004 09:03:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: GDB/MI snapshots between major release's In-Reply-To: <20041004212721.GB8846@white> References: <20041004205357.1FBCD502AB6@stray.canids> <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <20041004145921.BAC77502AB6@stray.canids> <20041004154928.GE8121@white> <20041004160455.DD23A502AB6@stray.canids> <20041004164803.GG8121@white> <20041004181201.9A8E9502AB6@stray.canids> <20041004183145.GH8121@white> <20041004205357.1FBCD502AB6@stray.canids> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-10/txt/msg00071.txt.bz2 At 17:27 04.10.2004 -0400, Bob Rossi wrote: >On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote: >> why would that happen? I expect 'create a new MI version' to be >> basically an atomic change. like, someone experiments with MI11 >> on a branch, then merges it into the trunk when it's stable and >> tests reasonable cleanly. > >This is frustrating to me, does anyone understand the problem that I am >describing? Maybe it could be said in a better way. I do, though I haven't a solution either. >Basically, a given GDB (from an official release) supports several MI protocols. >A given GDB from a CVS snapshot supports several MI protocols and 1 >unsupported protocol. > >The 1 unsupported protocol is the problem. One thing that could be added is that -i mi doesn't mean the last one (like mi2 now) but the last official one. So if there will be a mi3 in progress mi will still select mi2. Like that you will always be using the last stable protocol. And others can work with the development version by calling -i mi3. But that won't solve your problem of knowing what mi version the last stable really is. >During development, the first incompatible change forces the MI version >number to be bumped. Every incompatible change after that does not >effect the MI version number. Only after the release can the number be >bumped again (as far as I understand it). The release would be the point where -i mi changes from mi2 to mi3. >I am saying that I need to know if GDB is communicating with one of >these development MI protocols, because I want to use the last official >MI protocol, not a development MI protocol. To take your example: gdb --mi-protocols mi1 *mi2 mi3 which means that mi2 is the default (and therefore last stable) mi version. Like that you get all the necessary info about available and stable versions at once. bye Fabi