From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6957 invoked by alias); 4 Sep 2007 13:40:37 -0000 Received: (qmail 6947 invoked by uid 22791); 4 Sep 2007 13:40:37 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Sep 2007 13:40:30 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1ISYdl-0008WR-I2 for gdb@sources.redhat.com; Tue, 04 Sep 2007 17:40:26 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ISYdk-0008WK-Fv for gdb@sources.redhat.com; Tue, 04 Sep 2007 17:40:25 +0400 From: Vladimir Prus To: gdb@sources.redhat.com Subject: MI Development Date: Tue, 04 Sep 2007 13:40:00 -0000 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_GBW3Gmb31l1LhH8" Message-Id: <200709041740.22271.ghost@cs.msu.su> 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: 2007-09/txt/msg00026.txt.bz2 --Boundary-00=_GBW3Gmb31l1LhH8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 552 Hi, it should come as no surprise that the MI interface, as currently implemented in gdb, is not ideal. From experience working on KDevelop, I've created a list of issues with MI, which is attached to this email. That's something I'm planning to work on during my "KDevelop time", but it would be great to get some help: - If you think MI has some other import issues, let me know - If you, perhaps, would like to work on any of those issues, that will be even more appreciated -- just let me know so that we don't duplicate work. - Volodya --Boundary-00=_GBW3Gmb31l1LhH8 Content-Type: text/plain; charset="utf-8"; name="MI Development.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="MI Development.txt" Content-length: 1716 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. Pending breakpoints don't work It is not possible to create a pending breakpoint using MI interfaces. Further, when a pending breakpoint is resolved, the breakpoint number changes, and there's no MI notification for that. The second problem will be (accidentally) fixed by some upcoming CodeSourcery patches, but the first one needs separate work. 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. --Boundary-00=_GBW3Gmb31l1LhH8--