From: Phil Muldoon <pmuldoon@redhat.com>
To: Bob Rossi <bob@brasko.net>
Cc: Tom Tromey <tromey@redhat.com>, gdb@sourceware.org
Subject: Re: gdb/mi or python interface for front end
Date: Tue, 03 Sep 2013 21:25:00 -0000 [thread overview]
Message-ID: <522653B0.1070807@redhat.com> (raw)
In-Reply-To: <20130903012929.GA4379@bob-VirtualBox>
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
next prev parent reply other threads:[~2013-09-03 21:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-23 0:51 Bob Rossi
2013-08-23 14:03 ` Tom Tromey
2013-09-03 1:29 ` Bob Rossi
2013-09-03 21:25 ` Phil Muldoon [this message]
2013-09-03 23:37 ` Doug Evans
2013-08-23 14:07 ` Joel Brobecker
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=522653B0.1070807@redhat.com \
--to=pmuldoon@redhat.com \
--cc=bob@brasko.net \
--cc=gdb@sourceware.org \
--cc=tromey@redhat.com \
/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