From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12657 invoked by alias); 6 Jun 2006 01:56:27 -0000 Received: (qmail 12648 invoked by uid 22791); 6 Jun 2006 01:56:26 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Jun 2006 01:56:23 +0000 Received: from kahikatea.snap.net.nz (p202-124-112-224.snap.net.nz [202.124.112.224]) by viper.snap.net.nz (Postfix) with ESMTP id 08F127588F1; Tue, 6 Jun 2006 13:56:22 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 64F851D3550; Tue, 6 Jun 2006 13:55:41 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17540.57500.193504.704637@kahikatea.snap.net.nz> Date: Tue, 06 Jun 2006 01:56:00 -0000 To: Bob Rossi Cc: gdb-patches@sources.redhat.com Subject: Re: starting gdb/mi from FE In-Reply-To: <20060606013334.GE10045@brasko.net> References: <17540.53854.931145.771214@kahikatea.snap.net.nz> <20060606013334.GE10045@brasko.net> X-Mailer: VM 7.19 under Emacs 22.0.50.20 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/msg00056.txt.bz2 B> > > $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. But it won't work for *released* versions of GDB. >... > > 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. I don't see how, unless you plan to `recall' all released versions of GDB. > 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. If it changes from: (gdb) -mi-version ^done,major="3",minor="1" (gdb) your right, but I think this part of MI should be pretty constant. I imagine MI level changes involving things like asynchronous operation, event notification etc. > I think it's bad to provide > functionality that only works with makeshift parsers. I think we need to be practical and work within our limited resources. If a corporate sponsor comes along then maybe we can consider such general principles. -- Nick http://www.inet.net.nz/~nickrob