Re: [RFC 0/8] Create MI commands using python

Jan Vrany
2019-04-20T07:20:09Z

Hi,

On Thu, 2019-04-18 at 12:03 -0400, Simon Marchi wrote:
> On 2019-04-18 11:23 a.m., Jan Vrany wrote:
> > This patch series adds a possibility to create new MI commands using python.
> >
> > The code is based on a few year old attempt of Didier Nadeau who did the
> > heavy lifting. I merely updated his original code to work with today's GDB,
> > add tests and polished it a little.
> >
> > At this point, there's no documentation. I expect a discussion and changes
> > in behavior and/or output - I'll write it once the rest is agreed on.
>
> Hi Jan,
>
> Thanks for doing this!
>
> Here's the original thread:
> https://www.sourceware.org/ml/gdb-patches/2017-02/msg00088.html
>
> One thing Pedro asked for (rightfully), is some kind of rationale: what's the
> point of this feature. I'll try to provide some of it, since I helped Didier
> with this prototype at the time (done in an academic context). Jan, please
> complete/correct as needed to share your own point of view.
>
> As a GDB frontend developer, you want to display some application-specific data
> in your nice GUI frontend. That data is extracted from the application's data
> structure in memory, and possibly from doing some kind of bookkeeping (putting
> breakpoints at strategic points to record things) or whatnot.
>
> Today, it would be possible to do all of this in the front-end: you can read from
> memory and evaluate expressions to extract data from data structures in memory
> and you can put breakpoints to catch important events (which you try to hide from
> the user by resuming execution).
>
> The downside to this is that all the logic to reconstitute legible data from the
> data structures may be non-trivial, and all that logic will be in the front-end.
> If you want to support more than one front-end, or want to provide some similar
> feature from the command line as well, it will have to be duplicated.
>
> So the idea is to have a single implementation in Python, and have it accessible
> to the frontend. Today, you could implement a custom CLI command in Python and
> call it from MI, from your frontend. This is not ideal because the output would
> be CLI output, difficult to parse from MI (it's hard to know which output comes
> from which command).
> erSo the idea would be for front-ends to be able to load some scripts like:
>

Exactly! I could not have said it better. Another aspect may be performance - doing
extensive data structure analysis by walking variable object and/or inferior memory
in frontend can easily result in hundreds of MI commands being sent.

> class MyMICommand(gdb.MICommand):
> def __init__(self):
> super('-my-mi-command')
>
> def invoke(self, args):
> return {'foo': 'bar'}
>
> MyMICommand()
>
> This would define the '-my-mi-command' command, which when called, would return:
>
> 123-my-my-command
> 123^done,foo="bar"
>
> So to answer one question Pedro had:
>
> > I suppose they'll build the MI output "manually" ?
>
> Ideally not. They return a Python object (dict, list, string, int) which map pretty
> easily to MI data types.

Exactly. See parse_mi_result() in python/py-micmd.c
( https://bitbucket.org/janvrany/binutils-gdb/src/67fea07b27f59b5eb1dd99fe340d8222521e7df2/gdb/python/py-micmd.c?at=users%2Fjv%2Fvdb&fileviewer=file-view-default#py-micmd.c-36 )

To support even more OO style of programming, we can say that for
any other object ("generic" case in the code above), a define API
method - say .to_mi_record() - which must return one of the recognized
objects (string, int, sequence, dict, iterator).

I decided not to implement this until I get more experience with using
Python-defined MI commands for real.

Jan