From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15700 invoked by alias); 8 Mar 2010 20:17:45 -0000 Received: (qmail 15682 invoked by uid 22791); 8 Mar 2010 20:17:44 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Mar 2010 20:17:37 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o28KHaSu006243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Mar 2010 15:17:36 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o28KHZ1m027443; Mon, 8 Mar 2010 15:17:35 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o28KHYJE006621; Mon, 8 Mar 2010 15:17:34 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id E744C3782A7; Mon, 8 Mar 2010 13:17:33 -0700 (MST) From: Tom Tromey To: "Elmenthaler\, Jens" Cc: Subject: Re: MI Interface and Pretty Print to_string() result References: <58596C4646708B4BB990C4483997333001E4F2C5@usplmvpbe001.ent.rt.verigy.net> Reply-To: tromey@redhat.com Date: Mon, 08 Mar 2010 20:17:00 -0000 In-Reply-To: <58596C4646708B4BB990C4483997333001E4F2C5@usplmvpbe001.ent.rt.verigy.net> (Jens Elmenthaler's message of "Sun, 7 Mar 2010 04:16:19 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-03/txt/msg00050.txt.bz2 >>>>> "Jens" == Elmenthaler, Jens writes: Jens> - determine address and size of the value, most notably, to create Jens> a watchpoint from it. Well, here a new MI command would indeed Jens> help. In order to determine address and size, the CDT builds new Jens> expressions from the value (i.e. "&(value-expression)" and Jens> "sizeof(value-expression)"), and calls Jens> -data-evaluate-expression. This is what is no longer possible with Jens> children of dynamic variable objects. Thanks, this is very helpful. In many cases we could extract the address of a child value. This can be done whenever the printer returns a Value object that was taken from memory somewhere. Another issue with -var-info-path-expression that I remembered is that some of the expressions that we would want to return would actually be unparseble by any gdb older than CVS HEAD. At least, the libstdc++ printers do casts to qualified pointer types, which were broken. We may even need Keith's expr-cumulative merge to handle everything properly; I am not sure. Jens> For this, it would be sufficient, if gdb would map "v.[0]" to the Jens> child named "[0]". The pretty printers children() method provides Jens> all information that is need. The relative expression of a child Jens> to it's parent simple is the name of the child. The expressions Jens> resulting from it don't look like real C/C++ anymore, but this is Jens> something a user could possibly deal with. In the worst case, a Jens> gdb frontend could polish that up by using the disply hint Jens> information. Changing gdb to treat varobj names specially in an expression is probably difficult. I'm not sure it is wise, either. Having the printers emit "proper" expressions would also be nice... but this also runs afoul of other gdb expression bugs. In C++ in particular there are a number of unimplemented things. We're working on those, but it will be a while before they are all finished. Tom