From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4102 invoked by alias); 16 Nov 2006 21:36:22 -0000 Received: (qmail 4094 invoked by uid 22791); 16 Nov 2006 21:36:21 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.170) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Nov 2006 21:36:12 +0000 Received: by ug-out-1314.google.com with SMTP id k40so1245681ugc for ; Thu, 16 Nov 2006 13:36:09 -0800 (PST) Received: by 10.67.26.7 with SMTP id d7mr1006217ugj.1163712969173; Thu, 16 Nov 2006 13:36:09 -0800 (PST) Received: from ?192.168.0.11? ( [82.229.199.15]) by mx.google.com with ESMTP id p32sm2736152ugc.2006.11.16.13.36.08; Thu, 16 Nov 2006 13:36:09 -0800 (PST) Subject: Re: MI: frozen variable objects From: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Riss To: Vladimir Prus Cc: gdb-patches@sources.redhat.com In-Reply-To: References: <200611161547.46997.vladimir@codesourcery.com> <1163690698.3219.199.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Date: Thu, 16 Nov 2006 21:36:00 -0000 Message-Id: <1163712982.5060.226.camel@funkylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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/msg00150.txt.bz2 Le jeudi 16 novembre 2006 à 21:50 +0300, Vladimir Prus a écrit : > Frederic RISS wrote: > > The interesting part seems to be the one that hasn't been submited yet > > about GDB auto-freezing some values due to archtectural requirements. > > The debugger has architectural knowledge and it shouldn't be necessary > > to duplicate it in the GUI. > [...] > Since GUI typically rely to -var-update to read and report which values have > changed, it's best to change -var-update not to implicitly read > read-sensitive values. Doing this in GUI requires that GUI never > issues -var-update for a variable object that contains read-sensitive > children. That would be quite a drastic change in GUI architecture. > > With frozen variable object as implemented in the patch, GUI need only > localized straight-forward changes. First, note that I don't argue against adding support to the varobjs for ``frozen values'', even if that's what my mail sounded like :-). I gathered from your first mail that the ultimate goal is to add support in GDB for 'read-sensitive' data. That support shouldn't be limited to MI varobjs as Daniel pointed out. To get this support for the CLI, you'll certainly need low-level changes in GDB's value handling. If the above is right, then the low-level changes will prevent the varobj layer from fetching the data, and you kinda get the result you wanted. You'd just need to make sure that the data gets fetched when requested explicitly and to report the not-fetched-because-sensitive varobj state. Of course that would only work for read-sensitive data and wouldn't allow the GUI to freeze others values. If you believe this additional functionality would be useful to frontends, I think your opinion as a KDevelop developer is worth listening to :-) Fred.