From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13709 invoked by alias); 6 Jun 2006 02:01:44 -0000 Received: (qmail 13694 invoked by uid 22791); 6 Jun 2006 02:01:43 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao02.cox.net (HELO eastrmmtao02.cox.net) (68.230.240.37) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Jun 2006 02:01:41 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao02.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060606020138.VVHG15470.eastrmmtao02.cox.net@localhost.localdomain>; Mon, 5 Jun 2006 22:01:38 -0400 Received: from bob by localhost.localdomain with local (Exim 4.60) (envelope-from ) id 1FnQt5-0006xg-K5; Mon, 05 Jun 2006 22:01:43 -0400 Date: Tue, 06 Jun 2006 02:01:00 -0000 From: Bob Rossi To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: starting gdb/mi from FE Message-ID: <20060606020143.GG10045@brasko.net> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17540.53854.931145.771214@kahikatea.snap.net.nz> <20060606013334.GE10045@brasko.net> <17540.57500.193504.704637@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17540.57500.193504.704637@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/msg00057.txt.bz2 On Tue, Jun 06, 2006 at 01:55:40PM +1200, Nick Roberts wrote: > 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. Hmmm, I see your point. As soon as I support mi3, it won't work with these old released GDB's anymore. In that case, I'll know that I have to try start GDB with just mi2 on it's own. I don't see any other solution. > >... > > > 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. This solution works if you can guarentee that the protocol will never change. I don't care anything about the format of specific MI commands. > > 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. I'm confused, the patch I provided is about 20 lines of code. If you are talking about generating a parser, I've also done that with a 300 line bison input file. I think I'm misunderstanding you here. Bob Rossi