From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6158 invoked by alias); 7 Oct 2004 17:12:43 -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 6146 invoked from network); 7 Oct 2004 17:12:41 -0000 Received: from unknown (HELO epic.mail.pas.earthlink.net) (207.217.120.181) by sourceware.org with SMTP; 7 Oct 2004 17:12:41 -0000 Received: from ip216-26-76-19.dsl.du.teleport.com ([216.26.76.19] helo=stray.canids) by epic.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CFbon-0004ie-00 for gdb@sources.redhat.com; Thu, 07 Oct 2004 10:12:41 -0700 Received: from stray.canids (localhost.localdomain [127.0.0.1]) by stray.canids (Postfix) with ESMTP id 65B25502AB6 for ; Thu, 7 Oct 2004 10:12:40 -0700 (PDT) From: Felix Lee To: gdb@sources.redhat.com Subject: Re: probing GDB for MI versions References: <20041007140455.GA14402@white> <20041007143716.GB14402@white> In-Reply-To: <20041007143716.GB14402@white> on Thu, 07 Oct 2004 10:37:16 EDT from 'Bob Rossi' Date: Thu, 07 Oct 2004 18:01:00 -0000 Message-Id: <20041007171240.65B25502AB6@stray.canids> X-SW-Source: 2004-10/txt/msg00225.txt.bz2 'Bob Rossi' : > 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, that is why I am arguing on the side of not > adding this command to the MI function set, but solving the problem > another way. ... I'm lost. if I apply your statement to a different context, you seem to be saying that gdb's "show version" command is a nonsensical and confusing way of determining what version gdb is, and there should be an out-of-band method of determining gdb version. this seems to me obviously wrong, because there are many situations where you're limited to serial communication with a remote agent, so it isn't possible to get out-of-band information. that situation is unlikely to happen with gdb itself, since in any sane situation you're going to be able to invoke gdb with arbitrary command switches. but that's unusual rather than typical. most communication protocols need an in-band method of determining protocol version. it's not clear to me what assumptions you're making that lead you to dramatically different conclusions about what's "obvious". --