gdb/mi or python interface for front end

gdb/mi or python interface for front end

[Bob Rossi]

Hi,

I'm interested in improving the CGDB front end to GDB.

I would like some advice. It currently uses annotate level 2
for communication. Should I look into gdb/mi or should i look
into scripting gdb with the python interface?

Any pointers would be helpful.

Thanks,
Bob Rossi

Re: gdb/mi or python interface for front end

[Tom Tromey]

Bob> I would like some advice. It currently uses annotate level 2
Bob> for communication. Should I look into gdb/mi or should i look
Bob> into scripting gdb with the python interface?

Definitely stop using annotations.

MI is what all the other UIs for gdb use.  It is reasonably complete
and, while odd and/or buggy in some places, it is at least well known,
so you'll have plenty of company for either discussing bugs or
commiseration ;-)

I think using Python is cool, but I must admit it has a couple of
potential drawbacks.  First, it limits the versions of gdb your tool can
use -- older gdbs do not have Python, and it is an optional feature
(though most distros build it in).  Also, it is not as complete as MI in
some ways, so you may encounter holes that you need to be filled before
you can implement some feature.  On the plus side, I think interacting
with Python is generally simpler than interacting with MI.

Tom

Re: gdb/mi or python interface for front end

[Bob Rossi]

On Fri, Aug 23, 2013 at 08:03:27AM -0600, Tom Tromey wrote:
> Bob> I would like some advice. It currently uses annotate level 2
> Bob> for communication. Should I look into gdb/mi or should i look
> Bob> into scripting gdb with the python interface?
> 
> Definitely stop using annotations.

In the process.

> MI is what all the other UIs for gdb use.  It is reasonably complete
> and, while odd and/or buggy in some places, it is at least well known,
> so you'll have plenty of company for either discussing bugs or
> commiseration ;-)

OK. I'm curious if anyone knows if the MI protocol supports NUL
character bytes in it's output. I'm designing the protocol layer and
it would be convient to know if GDB transmits NUL character bytes
while sending output. (It's probably possible when printing a string
array?) An example would be awesome if so.

> I think using Python is cool, but I must admit it has a couple of
> potential drawbacks.  First, it limits the versions of gdb your tool can
> use -- older gdbs do not have Python, and it is an optional feature
> (though most distros build it in).

Which is why I'm still using annotations. Although that argument is
getting older.

> Also, it is not as complete as MI in
> some ways, so you may encounter holes that you need to be filled before
> you can implement some feature.

I'd like to avoid that.

> On the plus side, I think interacting
> with Python is generally simpler than interacting with MI.

I might end up with a hybrid approach. Bubble up my MI protocol and
also support python programming. I'm going to dig deeper at some point
in the future on this one.

Thanks,
Bob Rossi

Re: gdb/mi or python interface for front end

[Phil Muldoon]

On 03/09/13 02:29, Bob Rossi wrote:
> On Fri, Aug 23, 2013 at 08:03:27AM -0600, Tom Tromey wrote:
>> Bob> I would like some advice. It currently uses annotate level 2
>> Bob> for communication. Should I look into gdb/mi or should i look
>> Bob> into scripting gdb with the python interface?
>>
>> Definitely stop using annotations.
> 
> In the process.

Sorry I missed this email.  I must have been on PTO and it slipped
through.  Yes, agreed, annotations must die! ;)

>> I think using Python is cool, but I must admit it has a couple of
>> potential drawbacks.  First, it limits the versions of gdb your tool can
>> use -- older gdbs do not have Python, and it is an optional feature
>> (though most distros build it in).
> 
> Which is why I'm still using annotations. Although that argument is
> getting older.


It's my goal to be able to make the Python API able to do what you
wish, but there are some gaps.  For example, we don't have
asynchronous and rich inferior control.  That will come, hopefully
sooner than later.  You can get around it pretty much right now with
gdb.parse_and_eval and other like commands, but the feedback is all
text, which is problematic (text changes, as do error messages, and
there is no mark-up).  Soon, I hope, I will write inferior control
into the Python API.


>> Also, it is not as complete as MI in
>> some ways, so you may encounter holes that you need to be filled before
>> you can implement some feature.
> 
> I'd like to avoid that.

MI is pretty much designed to be a complement for IDEs/UIs as it uses
the concept of a wire protocol to communicate with GDB.  My goal with
the Python API is to make the API better suited to specific goals of
tools that use GDB for a narrower focus.  So you can write specific
tool-based solutions using it, instead of the catch all focus of the
IDE.  I don't think it is worthwhile to write the Python API to
replace MI;  MI is a known quantity used for this very purpose.
That being said, if you can write an entire front-end with Python,
then I would consider that an end-goal of the Python API.


> I might end up with a hybrid approach. Bubble up my MI protocol and
> also support python programming. I'm going to dig deeper at some point
> in the future on this one.

If I can help you on your approach, I would be happy to help.  Either
on the mailing list, or on the #gdb irc channel on freenode.

Cheers,

Phil

Re: gdb/mi or python interface for front end

[Doug Evans]

On Mon, Sep 2, 2013 at 6:29 PM, Bob Rossi <bob@brasko.net> wrote:
> OK. I'm curious if anyone knows if the MI protocol supports NUL
> character bytes in it's output. I'm designing the protocol layer and
> it would be convient to know if GDB transmits NUL character bytes
> while sending output. (It's probably possible when printing a string
> array?) An example would be awesome if so.

I looked into this.
IWBN if this were documented, otherwise I have to go on what I find
and I certainly could have missed something.
E.g., I see mi_console_raw_packet calling fputstrn_unfiltered
which calls printchar which escapes control characters.
I believe the answer is MI output will *never* contain the NUL char,
if present it will be quoted as \000.
[Again, I would be wrong, so heads up.  And corrections are most welcome.]

Re: gdb/mi or python interface for front end

[Joel Brobecker]

> I'm interested in improving the CGDB front end to GDB.
> 
> I would like some advice. It currently uses annotate level 2
> for communication. Should I look into gdb/mi or should i look
> into scripting gdb with the python interface?
> 
> Any pointers would be helpful.

I hope others who have more actual knowledge will answer, but
in case no one else does, my first reaction would be to look
into GDB/MI, because that's the interface that was designed
to be used by front ends. The Python API is getting very versatile,
but I don't know if it is going to provide everything you need
nor whether it'll be convenient to use. In particular, sending
commands, getting the output (with stdout and stderr separated),
etc.

-- 
Joel