From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2355 invoked by alias); 21 Feb 2006 18:12:51 -0000 Received: (qmail 2329 invoked by uid 22791); 21 Feb 2006 18:12:49 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Feb 2006 18:12:46 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k1LICRkU024585; Tue, 21 Feb 2006 10:12:27 -0800 (PST) Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay8.apple.com (Apple SCV relay) with ESMTP id 07D8B377; Tue, 21 Feb 2006 10:12:27 -0800 (PST) In-Reply-To: <200602210951.53705.ghost@cs.msu.su> References: <200602171724.03824.ghost@cs.msu.su> <200602201026.15624.ghost@cs.msu.su> <01627BAA-38C7-4391-A344-54B23B5F1863@apple.com> <200602210951.53705.ghost@cs.msu.su> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B18ED72-F372-4A1C-A6DF-9A5AA4A0826F@apple.com> Cc: GDB List Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: type prefixes for values Date: Tue, 21 Feb 2006 21:33:00 -0000 To: Vladimir Prus X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00283.txt.bz2 On Feb 20, 2006, at 10:51 PM, Vladimir Prus wrote: > On Monday 20 February 2006 21:58, Jim Ingham wrote: >> Making variable objects is always slower than just printing the >> values if you are only doing it one time. The variable objects don't >> do any magic to get their values - they go through the same code as >> "print" does ultimately, but they do a little more work getting >> there. The overhead is not all that great, however. Just malloc'ing >> some data structures and inserting them into a list somewhere. >> >> The advantage of variable objects is that they cache the parsed >> expression. So the second & third etc. evaluation is much faster. >> This is a pretty common usage pattern, especially with local >> variables, since you usually step a number of times in any given >> frame, and the locals all have to be updated with each step. The >> variable objects have some other convenient features, like the -var- >> update command which refreshes the values will report only the >> variable objects whose values have changed, so the front end has to >> fetch less data. > > Say, I've created a bunch of variable objects for for local > variables. When I > leave the function, those variables become invalid. How do you > detect this > case? Do you have a command '-list-var-objects-that-are-dead', or > some other > mechanism. We don't do this in gdb. Xcode keeps track of which varobj's go with which stack frames, and deletes them when appropriate. You want to be a little clever about this, 'cause there's no need to delete the varobj's till the function is actually popped off the stack. You might descend into another function then come back to this one, in which case the varobj's are still good. Note, however, that the varobj's do remember their frames, so if you tried to evaluate one that was no longer on the stack, the varobj would report "out of scope". > >> We also added the option to return all the locals in all the blocks >> in a function. This allows you to present all the variables, and >> then mark the ones which are not currently in scope appropriately. I >> find this less confusing than having the contents of the variables >> window come and go as you step through the function. Most of our >> users seem to agree. > > Heck, such a feature will immediately fix: > > http://bugs.kde.org/show_bug.cgi?id=120439 > > Is this patch available on some branch in the public CVS repository? No, it is just in the Apple sources. You can get these from the apple opensource repository: cvs -d pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root co gdb Our current TOT was last sync'ed up with the FSF sources about 6 months ago. Note, however, that in the area of variable objects, our sources are substantially different from the FSF sources. Jim > > - Volodya