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

[Jan Vrany <jan.vrany@fit.cvut.cz>]

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