From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16688 invoked by alias); 4 Oct 2004 18:12: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 16676 invoked from network); 4 Oct 2004 18:12:03 -0000 Received: from unknown (HELO epic.mail.pas.earthlink.net) (207.217.120.181) by sourceware.org with SMTP; 4 Oct 2004 18:12:03 -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 1CEXJa-0007aD-00 for gdb@sources.redhat.com; Mon, 04 Oct 2004 11:12:02 -0700 Received: from stray.canids (localhost.localdomain [127.0.0.1]) by stray.canids (Postfix) with ESMTP id 9A8E9502AB6 for ; Mon, 4 Oct 2004 11:12:01 -0700 (PDT) From: Felix Lee To: gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <20041004145921.BAC77502AB6@stray.canids> <20041004154928.GE8121@white> <20041004160455.DD23A502AB6@stray.canids> <20041004164803.GG8121@white> In-Reply-To: <20041004164803.GG8121@white> on Mon, 04 Oct 2004 12:48:03 EDT from Bob Rossi Date: Mon, 04 Oct 2004 18:31:00 -0000 Message-Id: <20041004181201.9A8E9502AB6@stray.canids> X-SW-Source: 2004-10/txt/msg00052.txt.bz2 Bob Rossi : > With the information I have now, here is the problem. A snapshot of GDB > will say that it is at MI4, although, it is really at some > developmental version. does that ever happen? if gdb says it supports MI4 but it doesn't really, then it's lying, and that's a bug. I think it's unreasonable to expect a front-end to have workarounds for every gdb bug. the best answer is often 'get a gdb without the bug'. it might be reasonable to have workarounds for bugs in gdb versions that are widely deployed, and that can be handled on a case-by-case basis. I don't have any objection to an --mi-protocols switch, but it seems to me that it isn't really needed by front-ends. one simple strategy is to just try each mi version you know until you find one that works. --