From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23015 invoked by alias); 17 Nov 2006 08:54:31 -0000 Received: (qmail 23004 invoked by uid 22791); 17 Nov 2006 08:54:30 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Nov 2006 08:54:22 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-01.spheriq.net with ESMTP id kAH8sI5T007041 for ; Fri, 17 Nov 2006 08:54:18 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id kAH8sHPS016862 for ; Fri, 17 Nov 2006 08:54:17 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id kAH8sETV030739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 17 Nov 2006 08:54:16 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 778F0DA42 for ; Fri, 17 Nov 2006 08:54:13 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0700E47253 for ; Fri, 17 Nov 2006 08:54:12 +0000 (GMT) Received: from [10.18.180.51] (crx3051.cro.st.com [10.18.180.51]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CIZ26001 (AUTH "frederic riss"); Fri, 17 Nov 2006 09:54:09 +0100 (CET) Subject: Re: MI: frozen variable objects From: Frederic RISS To: gdb-patches@sourceware.org In-Reply-To: References: <200611161547.46997.vladimir@codesourcery.com> <1163690698.3219.199.camel@localhost.localdomain> <1163712982.5060.226.camel@funkylaptop> Content-Type: text/plain Date: Fri, 17 Nov 2006 08:54:00 -0000 Message-Id: <1163753649.3219.227.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 Content-Transfer-Encoding: 7bit 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/msg00161.txt.bz2 On Fri, 2006-11-17 at 09:16 +0300, Vladimir Prus wrote: > > 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. > > That not exactly the design we planned. The value/type level will need two > changes: > > - Some flag on type or value to indicate it's read sensitive > - Some mechanism to allow presenting various target register, > scattered over address space, as a single structure > > At the same time, value level is not the right level to handle presentation > of read-sensitive values or make fetch/not fetch decisions. There's just > value_fetch_lazy function -- that fetches the raw data from the target. We > can either: > > (1) make value_fetch_lazy do nothing for read-sensitive values, > and add new value_fetch_really function that will read the value anyway, > or > (2) teach the clients of value_fetch_lazy to call it only when needed Well that's roughly what I meant. Once you get this groundwork in GDB, all you'll have to do to get the behavior you described is to propagate the explicitly-requested flag down to the varobj call to value_fetch_lazy. Maybe your additional changes are necessary to handle it gracefully. You've obviously studied this code more deeply and recently than I did. Fred.