From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23306 invoked by alias); 14 Jul 2008 20:10:04 -0000 Received: (qmail 23294 invoked by uid 22791); 14 Jul 2008 20:10:03 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 20:09:44 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 222B59813B; Mon, 14 Jul 2008 20:09:42 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 0BD189813A; Mon, 14 Jul 2008 20:09:42 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KIUMf-0005NB-1S; Mon, 14 Jul 2008 16:09:41 -0400 Date: Mon, 14 Jul 2008 20:10:00 -0000 From: Daniel Jacobowitz To: Keith Seitz Cc: frysk Subject: Re: GDB interface: MI versus API or ?? Message-ID: <20080714200941.GA20390@caradoc.them.org> References: <487B64C8.30707@redhat.com> <487B8266.9020601@redhat.com> <487BA20E.5050407@redhat.com> <487BA97C.203@redhat.com> <487BB090.1010807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487BB090.1010807@redhat.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00048.txt.bz2 On Mon, Jul 14, 2008 at 01:01:20PM -0700, 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. Just to expand on one thing here about CDT - many of you probably know this, but it hasn't come up on the list yet. It's got lots of debugger backends, and GDB/MI is just one of them. Most of the others are Java bindings to commercial (often non-Java) backends. DSF will be organized the same way. My understanding is that the GDB/MI-ness of the GDB backend is rarely a limiting factor. It's a bit complicating, but they've dealt with it. There are probably things that the GDB backend doesn't do and some other backends do, but they're more likely to be GDB limitations than MI limitations. A lot of front end developers approach GDB/MI as a black box. But recently we've had more success engaging them, getting feedback, and improving things. -- Daniel Jacobowitz CodeSourcery