* GDB interface: MI versus API or ??
@ 2008-07-14 14:38 Rick Moseley
2008-07-14 16:44 ` Phil Muldoon
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Rick Moseley @ 2008-07-14 14:38 UTC (permalink / raw)
To: frysk
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 14:38 GDB interface: MI versus API or ?? Rick Moseley
@ 2008-07-14 16:44 ` Phil Muldoon
2008-07-14 18:59 ` Rick Moseley
2008-07-14 19:30 ` Rick Moseley
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: Phil Muldoon @ 2008-07-14 16:44 UTC (permalink / raw)
To: Rick Moseley; +Cc: frysk
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 ;)
>
>
> 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 ....
But a very interesting set of responses. The data is good, lets hope
there is more of it!
Regards
Phil
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 16:44 ` Phil Muldoon
@ 2008-07-14 18:59 ` Rick Moseley
2008-07-14 19:11 ` Tom Tromey
0 siblings, 1 reply; 13+ messages in thread
From: Rick Moseley @ 2008-07-14 18:59 UTC (permalink / raw)
To: Phil Muldoon; +Cc: frysk
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 18:59 ` Rick Moseley
@ 2008-07-14 19:11 ` Tom Tromey
2008-07-14 19:31 ` Rick Moseley
0 siblings, 1 reply; 13+ messages in thread
From: Tom Tromey @ 2008-07-14 19:11 UTC (permalink / raw)
To: Rick Moseley; +Cc: Phil Muldoon, frysk
>>>>> "Rick" == Rick Moseley <rmoseley@redhat.com> writes:
Rick> One thing I thought of is if we did implement an MI protocol
Rick> that mimiced GDB's, would we pretty much automatically already
Rick> have the GUI's that have implemented MI for GDB available for
Rick> Frysk with some tweaking?
Yeah, assuming we could be compatible enough.
To me those responses pretty much indicated that the CDT developers do
not see MI as a limiter.
Tom
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 14:38 GDB interface: MI versus API or ?? Rick Moseley
2008-07-14 16:44 ` Phil Muldoon
@ 2008-07-14 19:30 ` Rick Moseley
2008-07-15 15:30 ` Sami Wagiaalla
2008-07-16 17:08 ` Dodji Seketeli
3 siblings, 0 replies; 13+ messages in thread
From: Rick Moseley @ 2008-07-14 19:30 UTC (permalink / raw)
To: frysk
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 19:11 ` Tom Tromey
@ 2008-07-14 19:31 ` Rick Moseley
2008-07-14 20:01 ` Keith Seitz
0 siblings, 1 reply; 13+ messages in thread
From: Rick Moseley @ 2008-07-14 19:31 UTC (permalink / raw)
To: Tom Tromey; +Cc: frysk
Tom Tromey wrote:
>>>>>> "Rick" == Rick Moseley <rmoseley@redhat.com> writes:
>>>>>>
>
> Rick> One thing I thought of is if we did implement an MI protocol
> Rick> that mimiced GDB's, would we pretty much automatically already
> Rick> have the GUI's that have implemented MI for GDB available for
> Rick> Frysk with some tweaking?
>
> Yeah, assuming we could be compatible enough.
>
> To me those responses pretty much indicated that the CDT developers do
> not see MI as a limiter.
>
My thoughts exactly.
> Tom
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
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
0 siblings, 2 replies; 13+ messages in thread
From: Keith Seitz @ 2008-07-14 20:01 UTC (permalink / raw)
To: frysk
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.
Keith
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 20:01 ` Keith Seitz
@ 2008-07-14 20:10 ` Daniel Jacobowitz
2008-07-14 20:11 ` Phil Muldoon
1 sibling, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2008-07-14 20:10 UTC (permalink / raw)
To: Keith Seitz; +Cc: frysk
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
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
1 sibling, 1 reply; 13+ messages in thread
From: Phil Muldoon @ 2008-07-14 20:11 UTC (permalink / raw)
To: Keith Seitz; +Cc: frysk
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 20:11 ` Phil Muldoon
@ 2008-07-14 20:18 ` Keith Seitz
2008-07-14 20:25 ` Phil Muldoon
0 siblings, 1 reply; 13+ messages in thread
From: Keith Seitz @ 2008-07-14 20:18 UTC (permalink / raw)
To: frysk
Phil Muldoon wrote:
> 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.
Almost certainly something MI-like, indeed. There is definitely a need
for a wire protocol for certain environments.
I'm just playing devil's advocate. [Remembering the uproar it caused on
the GDB mailing list a few years back, perhaps I should just keep to
myself...]
Keith
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 20:18 ` Keith Seitz
@ 2008-07-14 20:25 ` Phil Muldoon
0 siblings, 0 replies; 13+ messages in thread
From: Phil Muldoon @ 2008-07-14 20:25 UTC (permalink / raw)
To: Keith Seitz; +Cc: frysk
Keith Seitz wrote:
> Phil Muldoon wrote:
>
>> 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.
>
> Almost certainly something MI-like, indeed. There is definitely a need
> for a wire protocol for certain environments.
>
> I'm just playing devil's advocate. [Remembering the uproar it caused
> on the GDB mailing list a few years back, perhaps I should just keep
> to myself...]
>
> Keith
It think the (devil) advocate argument is a valuable one. I brought one
up earlier. I certainly value it; lets talk about the idea on its real
or theoretical merits. A deeper questions is why the folks over at CDT
think the MI protocol is ideal? Is it software conservatism? Is it
familiarity? Is it good-enough? Is MI good-enough to implement of of
most debugging problems? What are the limitations of MI?
Normally I find the edge-cases are the killers. Like someone who needs
to suck up 2G though the protocol straw, or various other extreme
drivers. Are they worthwhile cases? Do CDT have these cases?
It's all good. Lets think of them now while we are still in the thinking
stage ;)
Regards
Phil
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 14:38 GDB interface: MI versus API or ?? Rick Moseley
2008-07-14 16:44 ` Phil Muldoon
2008-07-14 19:30 ` Rick Moseley
@ 2008-07-15 15:30 ` Sami Wagiaalla
2008-07-16 17:08 ` Dodji Seketeli
3 siblings, 0 replies; 13+ messages in thread
From: Sami Wagiaalla @ 2008-07-15 15:30 UTC (permalink / raw)
To: Rick Moseley; +Cc: frysk
> "If you implement mi protocol it is less work on IDE side
...
> If Frysk was to use the MI protocol, I think its
> usage would be easier to implement for DSF.
...
> "MI is definitely the easiest way to integrate a debugger into CDT.
...
I think what they are saying is that MI is the easiest way to integrate
into the CDT. They are not saying much (neither good nor bad) about MI
as a technology.
Sami
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GDB interface: MI versus API or ??
2008-07-14 14:38 GDB interface: MI versus API or ?? Rick Moseley
` (2 preceding siblings ...)
2008-07-15 15:30 ` Sami Wagiaalla
@ 2008-07-16 17:08 ` Dodji Seketeli
3 siblings, 0 replies; 13+ messages in thread
From: Dodji Seketeli @ 2008-07-16 17:08 UTC (permalink / raw)
To: Rick Moseley; +Cc: frysk
Hello,
Rick Moseley a écrit :
> 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 am not an eclipse developer, but as I wrote a graphical debugger [1]
that uses GDB as a backend, I thought I could maybe share my thoughts on
this matter with you.
I think like anyone else that MI is not the easiest format on earth to
parse, but once you've written the code to parse it, well, it's there
and you'd want to leverage it as much as you can.
On the other hand, when you look at the whole interface it provides you
to talk with GDB - will call that the MI model - I am not sure that
interface is really optimal.
Please let me give some examples.
When you are stepping inside a function, you want different pieces of
state to be updated whenever that the relevant data changes in the
inferior. E.g, when the value of a field of a variable changes, you want
to detect that, and paint the field in red, in your variable editor.
In other words, you need an event oriented type of interface that can be
very granular. To limit the use of bandwith between the client and the
GDB backend, you'd like the client to register to the type of events she
wants, and then get notified when it's due.
Today, the MI model is not really oriented toward that direction. Maybe
it can be fixed, I don't know. But I can't say that I am very happy with
what it provides.
I think that what most GDB clients do today is to write an event driven
API that seats on top of MI, and that tries hard to plug the MI holes.
Those APIs integrate well with the mainloop technologies (Glib, or Qt
mainloops, for instance) so that the client can stay reactive to user
input without having to resort to multi-threading. This is also very
important, IMO.
Being enriched by that experience, I'd say that if a new debugger engine
(be it GDB or whatever) could come up with an API that seats on top of
it's (hidden) wire protocol, that would provide a fine grain event
driven model, and that could offer the possibility to integrate well in
the different mainloops out there it would be a big win for the end user.
As far as Nemiver is concerned, integrating that would "just" be a
matter of adding a new backend to the existing one. I am not saying it
wouldn't be work to do. But I do think it will give us a chance to
provide a better and snappier experience to our users. More than what we
have today with the current MI model.
Best regards,
Dodji.
[1] The debugger is Nemiver. You can read more about it at
http://en.wikipedia.org/wiki/Nemiver
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-07-16 17:08 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-14 14:38 GDB interface: MI versus API or ?? 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
2008-07-15 15:30 ` Sami Wagiaalla
2008-07-16 17:08 ` Dodji Seketeli
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).