From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31145 invoked by alias); 4 Sep 2007 15:06:36 -0000 Received: (qmail 31137 invoked by uid 22791); 4 Sep 2007 15:06:36 -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 15:06:29 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1ISZz0-0002V1-4V for gdb@sources.redhat.com; Tue, 04 Sep 2007 19:06: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 1ISZyy-0002Up-KJ; Tue, 04 Sep 2007 19:06:24 +0400 From: Vladimir Prus To: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= Subject: Re: MI Development Date: Tue, 04 Sep 2007 15:06:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb@sources.redhat.com References: <200709041740.22271.ghost@cs.msu.su> <200709041628.15560.apoenitz@trolltech.com> In-Reply-To: <200709041628.15560.apoenitz@trolltech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709041906.23252.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/msg00027.txt.bz2 On Tuesday 04 September 2007 18:28:15 Andr=C3=A9 P=C3=B6nitz wrote: > > 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 > > al type, using Apple's branch as reference. >=20 > Personally I think variable objects are not very well suited for C++ at a= ll. > Say, I want to display a "std::vector x"in a frontend I usually do n= ot > want to show three pointers to some internal data. Instead I usually want > to have x[0]...x[x.size()-1] as children. This is doable with variable o= bjects, > but the result feels clumsy, and the "update" feature cannot really be > used. I think we can fix that. I'd imagine we can make gdb invoke a Python hook on -var-list-children. That hook will compute values that correspond to vec= tor member and create variable objects out of those. There's some work on Python scripting already; I'd hope this use case will be kept in mind. There's extra problem is that MI is not prepared that the number of children of a variable objects can change -- and it can change in case of a vector. = We'd need to fix that. =20 > > Variable objects don't care much about C++ scopes. For example, it's no= t possible to > > create a variable object for a given expression in particular scope, wh= ich makes it impossible > > to accurately implement variable tooltips. Also, it's not possible to l= ist all local variables in the > > entire function, which requires extraordinary effort to display all loc= al variables as the enter > > scope and leave scope. >=20 > Yup. And there seems to be no way to reliably tell whether a (C++) variab= le has already been > constructed. This is indeed big problem, and I don't know if anybody's working on gettin= g gcc to produce accurate debug information for that. - Volodya