From: Rick Moseley <rmoseley@redhat.com>
To: frysk <frysk@sourceware.org>
Subject: Re: GDB interface: MI versus API or ??
Date: Mon, 14 Jul 2008 19:30:00 -0000 [thread overview]
Message-ID: <487BA930.7060809@redhat.com> (raw)
In-Reply-To: <487B64C8.30707@redhat.com>
Rick Moseley wrote:
> 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
A couple of more responses came in today pointing to another possible
option.
Pawel Piech:
"You may also want to consider the TCF debugger protocol currently being
developed in the Target Management project (see
http://wiki.eclipse.org/DSDP/TM/TCF_FAQ). It already has a reference
agent implementation (in C) that you could re-use, which would save you
the headache of implementing the MI protocol layer from scratch. Also,
as Marc pointed out GDB/MI protocol is evolving quite a lot to support
new features and keeping up with its changes will likely require
considerable effort. This shouldn't be a big surprise, as from my past
discussions with GDB developers I got the impression that GDB/MI as a
standard protocol to be implemented by other debuggers is definitely not
on their agenda."
Ken Ryall:
"We have been looking at some similar issues with debugger integration and
I'd like to second Pawel's suggest to look at TCF. If you have any questions
I'd be happy to share our experiences."
Hmmmmm, guess I'll dive a little deeper here and see what this TCF stuff is all about.
Rick
next prev parent reply other threads:[~2008-07-14 19:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-14 14:38 Rick Moseley
2008-07-14 16:44 ` Phil Muldoon
2008-07-14 18:59 ` Rick Moseley
2008-07-14 19:11 ` Tom Tromey
2008-07-14 19:31 ` Rick Moseley
2008-07-14 20:01 ` Keith Seitz
2008-07-14 20:10 ` Daniel Jacobowitz
2008-07-14 20:11 ` Phil Muldoon
2008-07-14 20:18 ` Keith Seitz
2008-07-14 20:25 ` Phil Muldoon
2008-07-14 19:30 ` Rick Moseley [this message]
2008-07-15 15:30 ` Sami Wagiaalla
2008-07-16 17:08 ` Dodji Seketeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=487BA930.7060809@redhat.com \
--to=rmoseley@redhat.com \
--cc=frysk@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).