From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1904 invoked by alias); 8 Oct 2004 07:08:18 -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 1737 invoked from network); 8 Oct 2004 07:08:14 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 8 Oct 2004 07:08:14 -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 i9878Clg009387 for ; Fri, 8 Oct 2004 09:08:13 +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 ; Fri, 08 Oct 2004 09:06:23 +0200 Message-Id: <5.2.0.9.1.20041008085646.0abdca60@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Fri, 08 Oct 2004 08:54:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: probing GDB for MI versions In-Reply-To: <20041007185010.GD14573@white> References: <20041007171240.65B25502AB6@stray.canids> <20041007140455.GA14402@white> <20041007143716.GB14402@white> <20041007171240.65B25502AB6@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/msg00239.txt.bz2 >For instance, XML allows the first line of the document to have the >version number. From then on, it can use the correct parser to process >the document. If the version number is not there, it can only guess at >what's in the document, and errors can occcur. Basically, the version >number is in a format the client can understand and then the client can >choose the appropriate parser based off of this. > >I think adding an MI command to get the version is not the solution to >this problem. Calling an MI command assumes that you already know the >protocol, and then you can call the MI function. Otherwise, you are not >necessarily handshaking, but you have to write the adhoc parser to get >the information you need. > >For instance, if GDB supported 1 stable MI protocol, if it is an >official release or a CVS snapshot, then the first thing GDB could >output to the front end is the version of MI that it is communicating. > >If we wanted to be even more verbose, we could > > * define a syntax for an MI header that communicated to the front > end all of the necessary things it would need to know before > initializing it's protocol. > > * we could always handshake using the MI2 protocol, even though the > protocol that GDB supports is a higher version. > >For option 2, this means that GDB would not necessarily support MI2, >but it would handshake in that protocol, since it will probably never >need to change for backward incompatibilities. This has the downside >of forcing new front ends to be able to implement the MI2 protocol, >which is probably not a good idea. Another example is the Auto-sense of Ethernet. Two partners start communicating with 10MBit as the least common denominator of Ethernet. Then they find they can both speak 100MBit and switch to this. Compared to gdb this would mean to start gdb with mi1, negotiate the version and then possibly switch to some higher mi version. But I think the switching is the part that doesn't work here (without restarting gdb, correct me if I'm wrong). Is it possbile to switch the mi version on the fly? If not, is this even considered a possible future extension? Or is it considered unneeded and wasted manpower as a working solution (restarting gdb) already exists? (I don't need this for myself. As I have to deliver a cross-compiled gdb with possibly some changes I will always know what mi version it can speak.) Thanks bye Fabi