From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6938 invoked by alias); 6 Jun 2006 01:33:33 -0000 Received: (qmail 6930 invoked by uid 22791); 6 Jun 2006 01:33:33 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao06.cox.net (HELO eastrmmtao06.cox.net) (68.230.240.33) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Jun 2006 01:33:31 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao06.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060606013329.EIGA16402.eastrmmtao06.cox.net@localhost.localdomain>; Mon, 5 Jun 2006 21:33:29 -0400 Received: from bob by localhost.localdomain with local (Exim 4.60) (envelope-from ) id 1FnQRq-0005AH-RE; Mon, 05 Jun 2006 21:33:34 -0400 Date: Tue, 06 Jun 2006 01:33:00 -0000 From: Bob Rossi To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: starting gdb/mi from FE Message-ID: <20060606013334.GE10045@brasko.net> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17540.53854.931145.771214@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17540.53854.931145.771214@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.11 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00054.txt.bz2 On Tue, Jun 06, 2006 at 12:54:54PM +1200, Nick Roberts wrote: > > $ ./gdb/gdb -q -i=mi ./main > > $~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n" > > $(gdb) > > > $$ ./gdb/gdb -q -i=mi4,mi3 ./main > > $mi_protocol_version=mi3 > > $~"Using host libthread_db library \"/lib/tls/i686/cmov/libthread_db.so.1\".\n" > > $(gdb) > > > $This will allow the FE to start GDB 1 time and to determine which > > $version of the protocol GDB was compatible with. If you have multiple > > $interpreter choices on the -i switch, then GDB will output the first > > $line it writes as > > $ mi_protocol_version=miN > > $where miN will be the version GDB is going to communicate with. > > > $This change is backwards compatible because users were not able in the > > $past to have a comma separated list in the -i flag. > > Backward compatible because it won't work with any version before GDB 6.5? Backward compatible because FE's can use mi2 when they do mi2, and mi3,mi2 when they do more than mi2. I'm thinking no front end will ever support mi1 (correct me if I'm wrong). Therefore, if we do this now, it'll work for most FE's. > > How does this look? > > I can't remember the previous outcome (I got lost with all the handshakes) but > I would prefer an MI command, -mi-version say, that the FE could use. It > could have a major and minor part: the major number to refer to the default MI > level; and the minor to help identify small changes made within one level. Of > course, we'd have to remember to update it, when appropriate. I would also not mind adding functionality like this on top of the solution I'm requesting. I think they both have there place. See below please. > Pre GDB 6.5 wouldn't really work in this case either, but > > (gdb) > -mi-version > ^error,msg="Undefined MI command: mi-version" > (gdb) > > wouldn't require restarting GDB, while: > > nickrob/21 gdb -i=mi2,mi1 myprog > Interpreter `mi2,mi1' unrecognized > nickrob/22 > > would. That's not correct. Unless you will work with mi1. It will work with mi2 on as described above. Also, the solution your provide is a chicken/egg problem. If anyone ever changes the MI output syntax in a non backwards compatible way, then I will not know which generated parser to use. If I don't know which generated parser to use, I can't possible call -mi-version and expect to parse the output. I think it's bad to provide functionality that only works with makeshift parsers. Thanks, Bob Rossi