From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16310 invoked by alias); 22 Dec 2006 06:23:44 -0000 Received: (qmail 16301 invoked by uid 22791); 22 Dec 2006 06:23:43 -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; Fri, 22 Dec 2006 06:23:39 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Gxdoc-0002fk-O4 for gdb-patches@sources.redhat.com; Fri, 22 Dec 2006 09:23:35 +0300 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 1GxdoS-0002e9-RR; Fri, 22 Dec 2006 09:23:25 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: variable objects and registers Date: Fri, 22 Dec 2006 06:23:00 -0000 User-Agent: KMail/1.9.1 Cc: Jim Ingham , gdb-patches@sources.redhat.com References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <1B6B17FA-65DE-4CE2-9BE0-20DA74780EEA@apple.com> <17803.25142.328258.338868@kahikatea.snap.net.nz> In-Reply-To: <17803.25142.328258.338868@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612220923.22655.ghost@cs.msu.su> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00301.txt.bz2 On Friday 22 December 2006 07:42, Nick Roberts wrote: > > Sadly, neither Jason nor I will get a chance to do anything other > > that our already scheduled tasks till we're done with Leopard - > > sometime middle of next year or thereabouts. We have a lot on our > > plates till then, and don't have any time available for this. I > > can't really say what our plans will be after that. > > OK, well thanks for the pointers anyway. > > > >> Another kind of useful addition along the same lines, we extended the > > >> "FRAME" argument to -var-create so you can say: > > >> > > >> -var-create - +main.c:6 bar > > >> > > >> to create the variable object for bar in the scope surrounding line > > >> 6. This is necessary if you want to do variable values in tooltips > > >> using variable objects. > > > > > > Yes, I see Insight uses variable objects for tooltips too. What > > > advantage do > > > they have over just using "print"? > > > > The Xcode tooltips allow structure expansion & formatting the same > > way the locals display does. Using varobj's for this makes the code > > uniform, and simpler. > > Insight just prints the type as a tooltip for structures. You seem to be > saying that in Xcode you can do this and choose to expand it. Using "print" > in Emacs, everything is automatically expanded which I must admit is messy > with a large array or structure. Perhaps -data-evaluate-expression could > be modified to print "--simple-values" or "--all-values" as -stack-list-locals > does. I think it's much better to use varobjs for tooltips. It's much better for structures. > Actually I see Insight gets it wrong, when one variable masks another with > the same name, just printing the current value. I guess variable objects > allow such values to be correctly accessed, but they generally they seem > to be designed for tracking values rather than getting instantaneous ones > as with tooltips. There's no reason why -var-create cannot be extended to also specify line at which the expression must be evaluated -- computing the right block. - Volodya