From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16998 invoked by alias); 14 Jul 2008 14:38:24 -0000 Received: (qmail 16981 invoked by uid 22791); 14 Jul 2008 14:38:21 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_05,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 14:38:04 +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 m6EEc2e1017971 for ; Mon, 14 Jul 2008 10:38:02 -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 m6EEc1SY026259 for ; Mon, 14 Jul 2008 10:38:01 -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 m6EEc1ws024844 for ; Mon, 14 Jul 2008 10:38:01 -0400 Message-ID: <487B64C8.30707@redhat.com> Date: Mon, 14 Jul 2008 14:38:00 -0000 From: Rick Moseley User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: frysk Subject: GDB interface: MI versus API or ?? 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/msg00030.txt.bz2 Hi all. Last week I posed the question on the Eclipse cdt-dev list as to which of the gdb interfaces were preferred for integrating with Eclipse CDT. I have received 3 responses so far and here they are: Elena Laskavaia: "If you implement mi protocol it is less work on IDE side (just another launch config), however mi does not support all commands and mi integration use "CDI" (user gdb) commands too, which makes it ugly. The other approach is to create another implementation of this layer for your specific debugger, which would be more work but it may be more robust." 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. 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. So, I think from an "amount of work" point-of-view, using MI is better. >From a "best technical solution" point-of-view, I don't have enough experience to have an opinion." Mikhail Khodjaiants: "MI is definitely the easiest way to integrate a debugger into CDT. If implemented it will be automatically picked up by existing CDI and DSF gdb/MI debuggers. But if the API library provides more functionality than MI it might be worth to consider a direct integration using one of the existing frameworks. But it would require a lot of work and resources." 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. Anyways, there are the responses from the Eclipse CDT community so far, what are your thoughts on the subject? Rick