From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106416 invoked by alias); 18 Apr 2019 16:03:18 -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 106401 invoked by uid 89); 18 Apr 2019 16:03:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:172.16.0, strategic, his X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Apr 2019 16:03:15 +0000 Received: from [172.16.0.120] (192-222-157-41.qc.cable.ebox.net [192.222.157.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1023B1E093; Thu, 18 Apr 2019 12:03:13 -0400 (EDT) Subject: Re: [RFC 0/8] Create MI commands using python To: Jan Vrany , gdb-patches@sourceware.org References: <20190418152337.6376-1-jan.vrany@fit.cvut.cz> From: Simon Marchi Message-ID: <8fe6b394-b1d4-6207-b9f6-acdfce4002bd@simark.ca> Date: Thu, 18 Apr 2019 16:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190418152337.6376-1-jan.vrany@fit.cvut.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-04/txt/msg00341.txt.bz2 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). So the idea would be for front-ends to be able to load some scripts like: 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. Simon