Re: GDB interface: MI versus API or ??

[Dodji Seketeli <dseketel at redhat dot com>]

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