From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15223 invoked by alias); 22 Dec 2006 04:47:23 -0000 Received: (qmail 15215 invoked by uid 22791); 22 Dec 2006 04:47:22 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Dec 2006 04:47:14 +0000 Received: from kahikatea.snap.net.nz (p202-124-120-122.snap.net.nz [202.124.120.122]) by viper.snap.net.nz (Postfix) with ESMTP id CD28F3D8A14; Fri, 22 Dec 2006 17:48:43 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id BE6E0BE457; Fri, 22 Dec 2006 17:42:31 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17803.25142.328258.338868@kahikatea.snap.net.nz> Date: Fri, 22 Dec 2006 04:47:00 -0000 To: Jim Ingham Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: variable objects and registers In-Reply-To: <1B6B17FA-65DE-4CE2-9BE0-20DA74780EEA@apple.com> References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <17801.40268.835284.224413@kahikatea.snap.net.nz> <200612210942.54734.ghost@cs.msu.su> <17802.17932.377094.90049@kahikatea.snap.net.nz> <0E190425-7C4F-4C6E-B8B3-9A3FA79F6FE3@apple.com> <17803.6117.15940.138752@kahikatea.snap.net.nz> <1B6B17FA-65DE-4CE2-9BE0-20DA74780EEA@apple.com> X-Mailer: VM 7.19 under Emacs 22.0.92.1 X-IsSubscribed: yes 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/msg00298.txt.bz2 > 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. 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. -- Nick http://www.inet.net.nz/~nickrob