From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30217 invoked by alias); 6 Oct 2004 18:19:06 -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 30209 invoked from network); 6 Oct 2004 18:19:04 -0000 Received: from unknown (HELO lakermmtao02.cox.net) (68.230.240.37) by sourceware.org with SMTP; 6 Oct 2004 18:19:04 -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 <20041006181904.FOIW23897.lakermmtao02.cox.net@white> for ; Wed, 6 Oct 2004 14:19:04 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFGNT-0003Mq-00 for ; Wed, 06 Oct 2004 14:19:03 -0400 Date: Wed, 06 Oct 2004 18:30:00 -0000 From: Bob Rossi To: GDB Subject: probing GDB for MI versions (summary) Message-ID: <20041006181903.GM12213@white> Mail-Followup-To: GDB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00168.txt.bz2 Hi, It seems that at this point, everyone agrees there needs to be a command in GDB that allows it to output the official versions of MI that it supports. I think this is very good, since it addresses many of the problems that I am facing. So far there have been several proposals, * A command line switch * A new interpreter that outputs the interpreters that GDB supports * A new MI command * Starting GDB with every possible interpreter, until one is found. I originally like the command line switch, which Eli disapproved of because of the general public having access to useless information. I agree with Eli on this point, and I came up with the idea from Nathan's Email that a new interpreter could be invoked, and the interpreter was only capable of outputting the interpreters that the current GDB supports. This is a simple solution and I would prefer to see it implemented. It avoids the problem that Eli had. Adding a new MI command is the worst case scenario in my opinion. The reason is because a front end that understands all of the MI protocols can not use any of them to ask GDB what protocols it supports. The front end has to come up with some new parser, that has to understand future protocols that have not been invented. Starting GDB with every possible interpreter. This solution is workable but is ugly and could make the user wait for GDB to be started several times for no reason at all. Also, the problem with developmental versions is still an issue on this approach. Any comments? Thanks, Bob Rossi