From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4330 invoked by alias); 22 Feb 2008 06:44:09 -0000 Received: (qmail 4320 invoked by uid 22791); 22 Feb 2008 06:44:08 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Feb 2008 06:43:26 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JSRcv-0006Mh-7c for gdb@sources.redhat.com; Fri, 22 Feb 2008 06:43:21 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2008 06:43:21 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2008 06:43:21 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: New MI maintainer Date: Fri, 22 Feb 2008 08:43:00 -0000 Message-ID: References: <20080219191222.GA10196@caradoc.them.org> <20080221192124.GJ31574@brasko.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart4072440.gZRMEpL8TL" Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00178.txt.bz2 --nextPart4072440.gZRMEpL8TL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit Content-length: 458 Bob Rossi wrote: > On Tue, Feb 19, 2008 at 02:12:22PM -0500, Daniel Jacobowitz wrote: >> I'm glad to announce that GDB finally has an official MI maintainer >> again: Vladimir Prus. > > Congratulations Vladmir. Thanks. > Could you tell us if you have any goals as the official MI maintainer? Attached is my current list of MI problems that I find most important to resolve. The item most close to completion is custom display of varobjs. - Volodya --nextPart4072440.gZRMEpL8TL Content-Type: text/plain; name="MI Development(2).txt" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="MI Development(2).txt" Content-length: 2279 MI Development The GDB/MI interface as it is today has the following important problems. Variable objects and RTTI For C++, variable objects are not able to look at the real type of the object. Only the static type is shown. We should be able to implement display of real type, using Apple's branch as reference. CLI commands bypass MI When a CLI command is issued, we don't see "^running". As result, frontend can easily think that gdb is waiting for commands while inferior is running. Variable objects and scopes Variable objects don't care much about C++ scopes. For example, it's not possible to create a variable object for a given expression in particular scope, which makes it impossible to accurately implement variable tooltips. Also, it's not possible to list all local variables in the entire function, which requires extraordinary effort to display all local variables as the enter scope and leave scope. Change notification style Generally, all commands that a frontend might want to issue at each step -- list of breakpoints, list of threads, list frames, list of local variables -- should have a notification to match, which is emitted whenever gdb thinks the result of those command can possibly change. Wit this, the frontend won't have to automatically issue any commands after step -- if anything changes, gdb will report that itself. Static fields The way -var-list-children displays always displays static field is a bit annoying, it can also result in nice never ending trees, like in https://bugs.eclipse.org/bugs/show_bug.cgi?id=136627 Need to make it customizable. Custom display For many kinds of objects there's some more reasonable representation than pure varobj tree. For example -- for QString we need the real string. For vector we need content of the vector to be the children.  This requires some scripting level, that can customize creation of children of variable object and display as string.  In order for -var-update to work, that customization level should actually be able to construct arbitrary value and use that value for a variable object. For -var-update together with vector, we should be able to check if the vector size/storage has changed. I'm not sure how we'd create new children if a vector is resized. --nextPart4072440.gZRMEpL8TL--