From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10816 invoked by alias); 16 Nov 2006 21:53:19 -0000 Received: (qmail 10805 invoked by uid 22791); 16 Nov 2006 21:53:18 -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; Thu, 16 Nov 2006 21:53:08 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-197.snap.net.nz [202.124.125.197]) by viper.snap.net.nz (Postfix) with ESMTP id BCDA13D9303; Fri, 17 Nov 2006 10:53:27 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 34C36BE43D; Fri, 17 Nov 2006 10:49:01 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17756.56523.353271.828046@kahikatea.snap.net.nz> Date: Thu, 16 Nov 2006 21:53:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: MI: frozen variable objects X-Mailer: VM 7.19 under Emacs 22.0.90.14 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00151.txt.bz2 > This patch introduces so called "frozen" variable objects -- variable objects > that are not implicitly updated by the "-var-update *" command or by > "-var-update" on parent variable objects. This explains your previous patch (Variable objects laziness): + We do this for frozen varobjs as well, since this + function is only called when it's decided that we need + to fetch the new value of a frozen variable. */ I've not experienced a need for such functionality probably because my Emacs mode is still unreleased and therefore has a very small user base. Since you and Daniel J see that it is needed (through Eclipse?) it seems sensible to install a patch like this (and the earlier one, which I do understand now - perhaps the ChangeLog could say "Use install_new_value instead of gdb_value_fetch_lazy"). However, I would just suggest that these changes are made shortly after the release of GDB 6.6. That way there is time test them with frontends that might be using GDB/MI while GDB is still in CVS. -- Nick http://www.inet.net.nz/~nickrob