From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23842 invoked by alias); 14 Jul 2008 20:11:28 -0000 Received: (qmail 23835 invoked by uid 22791); 14 Jul 2008 20:11:27 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 20:11:05 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6EKB3SF020917 for ; Mon, 14 Jul 2008 16:11:03 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6EKB3qe017874; Mon, 14 Jul 2008 16:11:03 -0400 Received: from localhost.localdomain (vpn-4-54.str.redhat.com [10.32.4.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6EKB1ON015057; Mon, 14 Jul 2008 16:11:02 -0400 Message-ID: <487BB2D4.1090702@redhat.com> Date: Mon, 14 Jul 2008 20:11:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Keith Seitz CC: frysk Subject: Re: GDB interface: MI versus API or ?? References: <487B64C8.30707@redhat.com> <487B8266.9020601@redhat.com> <487BA20E.5050407@redhat.com> <487BA97C.203@redhat.com> <487BB090.1010807@redhat.com> In-Reply-To: <487BB090.1010807@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00049.txt.bz2 Keith Seitz wrote: > Rick Moseley wrote: >>> To me those responses pretty much indicated that the CDT developers do >>> not see MI as a limiter. >>> >> My thoughts exactly. > > Is that really true, though? Do they have any other choice but gdb/MI? > > The responses sound more like they welcome a "better"/enhanced > debugger backend (who wouldn't), but they've got a good, mature > product and plenty of other work to do, too. So MI is "good enough". > > We shouldn't confuse "good" with "good enough". But perhaps the cynic > is me needs to be beaten into submission again. That's my read too. Just because they have MI and it works, does it mean that it could be improved on? Bettered? But unless we come up with a better way, then automatically we're just quoting optimistic theory over actual implementation. To be honest, I think eventually whatever we come up with, if it is not improving GDB, we'll end up at last emulating an MI interface. Just because everything uses it already. Regards Phil