From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10872 invoked by alias); 13 Oct 2004 12:14:17 -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 10737 invoked from network); 13 Oct 2004 12:14:14 -0000 Received: from unknown (HELO lakermmtao02.cox.net) (68.230.240.37) by sourceware.org with SMTP; 13 Oct 2004 12:14:14 -0000 Received: from white ([68.9.64.121]) by lakermmtao02.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041013121412.IFOJ27002.lakermmtao02.cox.net@white>; Wed, 13 Oct 2004 08:14:12 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CHi1E-0005uf-00; Wed, 13 Oct 2004 08:14:12 -0400 Date: Wed, 13 Oct 2004 14:05:00 -0000 From: 'Bob Rossi' To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041013121412.GA22696@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20041007145511.GA14573@white> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4b0df$Blat.v2.2.2$e933d3e0@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00303.txt.bz2 On Wed, Oct 13, 2004 at 06:47:37AM +0200, Eli Zaretskii wrote: > > Date: Tue, 12 Oct 2004 20:31:35 -0400 > > From: 'Bob Rossi' > > > > With this idea there are 2 alternatives I can think of. > > * put the handshaking under a different interpreter (-i=mi-handshake) > > * integrate the handshaking as part of the MI protocol (version 3 and on) > > What's wrong with a simpler idea already suggested here: that GDB will > output the MI version as part of the starting blurb when invoked with > "-interpreter=mi" option? That method is fine if GDB supports only one stable MI protocol at a time. However, I have been told that GDB will support multiple versions of MI at a time. If GDB supported only one stable MI version at a time, then it could just do what you are saying, tell the front end what version it is going to output. This is basically how XML and HTML documents work. The first line is the version of the file, and the client reads that and uses the appropriate parser. However, GDB is not that simple. It can support several versions of the MI protocol. Some of the versions can be developmental, others can be stable, and others can be unstable. For instance, the current GDB has mi2 being stable, and mi1 being unstable (not tested). For this reason, GDB and the front end actually need to handshake to determine what protocol should be used. I'm assuming that this is more like the Ethernet example someone brought up were all of the devices have to query each other to figure out what protocol to use. Here is something I came up with last night, GDB/MI Handshaking output mi-handshake-input => mi-protocol-output [ "," mi-protocol-output ]* nl mi-protocol-output => mi-protocol-class "=" mi-protocol mi-protocol-class => "mi_unsupported" | "mi_supported" | "mi_development" mi-protocol => "mi" digit digit => 1 | 1 + digit nl => CR | CR NL | NL GDB/MI Handshaking input mi-handshake-input => mi-protocol nl Obviously, that results in GDB outputting something like, mi_unsupported=mi1,mi_supported=mi2,mi_development=mi3 and the front end sending to GDB simply "mi2". Thanks, Bob Rossi