From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6349 invoked by alias); 14 Jul 2008 18:59:48 -0000 Received: (qmail 6339 invoked by uid 22791); 14 Jul 2008 18:59:47 -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 18:59:30 +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 m6EIxScF026440 for ; Mon, 14 Jul 2008 14:59:28 -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 m6EIxRGA022299; Mon, 14 Jul 2008 14:59:27 -0400 Received: from localhost.localdomain (vpn-12-143.rdu.redhat.com [10.11.12.143]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6EIxRqa028097; Mon, 14 Jul 2008 14:59:27 -0400 Message-ID: <487BA20E.5050407@redhat.com> Date: Mon, 14 Jul 2008 18:59:00 -0000 From: Rick Moseley User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Phil Muldoon CC: frysk Subject: Re: GDB interface: MI versus API or ?? References: <487B64C8.30707@redhat.com> <487B8266.9020601@redhat.com> In-Reply-To: <487B8266.9020601@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/msg00043.txt.bz2 Phil Muldoon wrote: > Rick Moseley wrote: > > Hi rick. Interesting reponses. >> >> Marc Khouzam: >> >> "The new DSF-based debugging frontend that can also be used with the CDT >> also has an MI layer. If Frysk was to use the MI protocol, I think its >> usage would be easier to implement for DSF. > > Why not implement a Frysk "module/plug-in/back-end/whatever" for DSF? > If CDT implements the debugger via DSF, it should not matter then? > >> >> Also, GDB is evolving the MI interface for such things as non-stop >> debugging and multi-process debugging. So, MI has some effort being >> put into it. I believe an API library would need to be defined from the >> start, which seems to be more work, for Frysk and for DSF. > > Cite ;) After seeing this response last Friday I started looking at DSF a little closer to see what I could find out. > >> >> >> From these responses it seems the MI is alive and well inside the >> Eclipse CDT. Although it would seem to me the API approach would be >> more robust/full-featured, there does not seem to be any >> qualms/objections to using the MI protocol. If there are new >> features being made to MI in the gdb community it might be the way to >> go if it indeed fleshes out the functionality. We could implement >> the gdb MI protocol and then add "Frysk extensions" to get the >> additional functionality we require. >> > > It sure is, but what else is there, out-there now to compare it too? > I'm not against MI, or GDB (and am playing a large degree of devil's > advocate here), but if you ask the a bunch of MI hackers what's best > since sliced bread .... I'm not sure I would classify the CDT developers as MI hackers exactly, although I am sure there is some bias there as they know that protocol well by now. They are using the only tool they have been given to work with GDB. I guess I was surprised that offering them *any* choice of tool their heart could desire to talk to a debugger and the chance to drop MI like a hot rock, they did not seem that eager to jump to another tool. So, they do not seem to have a massive dislike for MI as I might have thought. One thing I thought of is if we did implement an MI protocol that mimiced GDB's, would we pretty much automatically already have the GUI's that have implemented MI for GDB available for Frysk with some tweaking? I don't have enough knowledge about the GDB GUI's out there to know for sure. > > But a very interesting set of responses. The data is good, lets hope > there is more of it! > > > Regards > > Phil