From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8269 invoked by alias); 7 Oct 2004 16:14:04 -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 8253 invoked from network); 7 Oct 2004 16:14:02 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 7 Oct 2004 16:14:02 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id MAA21438 for ; Thu, 7 Oct 2004 12:08:59 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id MAA31899 for gdb@sources.redhat.com; Thu, 7 Oct 2004 12:14:00 -0400 Message-Id: <200410071614.MAA31899@smtp.ott.qnx.com> Subject: Re: probing GDB for MI versions To: bob@brasko.net ('Bob Rossi') Date: Thu, 07 Oct 2004 16:45:00 -0000 From: "Alain Magloire" Cc: dk@artimi.com (Dave Korn), gdb@sources.redhat.com In-Reply-To: <20041007145511.GA14573@white> from "'Bob Rossi'" at Oct 07, 2004 10:55:11 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00221.txt.bz2 > > On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote: > > > -----Original Message----- > > > From: 'Bob Rossi' > > > Sent: 07 October 2004 15:37 > > > > > I understand that adding an MI command to the MI function set that can > > > not be accessed by a front end that understands the MI protocol is > > > nonsensical and confusing > > > > Since nobody has proposed such an addition, your opinion of it is utterly > > irrelevant. > > Again, you do not understand the issue. > > Adding this new function -mi-version, will be adding the first command > to the MI command set that is supposed to be used by a front end by > *not* using an MI protocol. It is confusing and non-sensical to add the > first MI command to the MI command set that can not be used by a front > end that speaks the MI protocol. > (I have this funny feeling, that you guys are going in circle ! Am I missing an important piece of the puzzle ?) Bob, I thought I was following your way of thinking but you lost me there. One of the reason(correct me If I'm wrong) to add -mi-version is if the front-end start gdb like this $ gdb -i=mi executable Doing "-mi-version" will let the front-end adjust which parser to instanciate. But after that, you seem to get lost on implementation details, chicken and egg problem, with reasoning like: we need to parse the "-mi-version" with an MI parser but wait ... we can not start the parser since we do not know yet which parser to instanciate. Davek's point(which I tend to agree with) is saying you need to bootstap somehow. Let's focus for a second on this issue, from the 3 scenarios below which one will be satisfactory for you: 1- front end starts gdb with different mi version until it finds a good one $gdb -i=mi4 # fails $gdb -i=mi3 # fails $gdb -i=mi2 # sucess, start debuging 2- front end choose the protocol form the list of known $gdb --list-protocols 3- the -mi-version (1) looks allright and no changes is needed (2) could be nicer (3) is ok.