public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
* 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).