From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12508 invoked by alias); 5 Nov 2010 17:14:20 -0000 Received: (qmail 12397 invoked by uid 22791); 5 Nov 2010 17:14:18 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_20,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-mx09.nokia.com) (192.100.105.134) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Nov 2010 17:14:13 +0000 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA5HD5Yb005009; Fri, 5 Nov 2010 12:13:57 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Nov 2010 19:13:36 +0200 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Nov 2010 19:13:35 +0200 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA5HDXJg019575; Fri, 5 Nov 2010 19:13:34 +0200 From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: ext Tom Tromey , "gdb@sourceware.org" Subject: Re: gdb with python support still get crash on showing uninitialized local variables Date: Fri, 05 Nov 2010 17:14:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.2; i686; ; ) References: <4CB66700.3000907@gmail.com> <201010142029.24092.andre.poenitz@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201011051812.27358.andre.poenitz@nokia.com> X-Nokia-AV: Clean 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: 2010-11/txt/msg00028.txt.bz2 On Saturday 16 October 2010 00:38:23 you wrote: > >>>>> "Andr=C3=A9" =3D=3D Andr=C3=A9 P=C3=B6nitz writes: >=20 > Andr=C3=A9> However, I do not use the gdb version of the pretty printers = for > Andr=C3=A9> the stability reason you just encountered, and because they > Andr=C3=A9> cannot (easily...) create several layers including possibly > Andr=C3=A9> "virtual" ones that do not correspond to actual objects on the > Andr=C3=A9> inferior side. >=20 > I don't understand this latter comment, but I would like to. > Could you give an example? Or explain it in more depth? The MI varobject based infrastructure creates one level of information at a time. So it is not easy to create displays of "virtual levels" or items that do not actually "live" in the inferior. Displays like Name Value Type someObject 0x2312413 SomeType properties=20 property1 "MyName" String (stored in a = member of the object) property2 Nov 11, 2010 Date (perhaps in cur= rent locale) property3 "Some Street" String (perhaps comin= g from a database) children ... parents ... connections ... are very hard to create in this world, yet such display can be _very_=20 convenient when debugging applications above the "bare metal" level. I actually claim that certain displays are impossible to handle with the MI varobject approach -- even under the assumption that it would work well otherwise (i.e. handle anonymous structs, hidden variables in outer scope, gracefully cope with uninitialized/corrupted data, need not several roundtrips to setup, had a way to reduce repeated data etc) I seriously believe that with full python scripting being available in gdb there is no need to use MI varobjects at all.=20 Unfortunately, gdb's own python based pretty printing does not use this new freedom but is modeled very similar to the varobject setup=20 and therefore shares (needlessly if I may add) some of the varobject=20 shortcomings. Andre'