From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2988 invoked by alias); 20 Apr 2019 07:20:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2979 invoked by uid 89); 20 Apr 2019 07:20:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=Today, Vrany, vrany, H*r:user X-HELO: relay.fit.cvut.cz Received: from relay.fit.cvut.cz (HELO relay.fit.cvut.cz) (147.32.232.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 20 Apr 2019 07:20:06 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [147.32.232.238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id x3K7JxCb053817 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Apr 2019 09:20:00 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Received: from sao (02d97c6d.bb.sky.com [2.217.124.109] (may be forged)) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id x3K7JtpZ018584 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 20 Apr 2019 09:19:56 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: Subject: Re: [RFC 0/8] Create MI commands using python From: Jan Vrany To: Simon Marchi , gdb-patches@sourceware.org Date: Sat, 20 Apr 2019 07:20:00 -0000 In-Reply-To: <8fe6b394-b1d4-6207-b9f6-acdfce4002bd@simark.ca> References: <20190418152337.6376-1-jan.vrany@fit.cvut.cz> <8fe6b394-b1d4-6207-b9f6-acdfce4002bd@simark.ca> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-04/txt/msg00395.txt.bz2 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