From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19527 invoked by alias); 17 Nov 2006 06:17:31 -0000 Received: (qmail 19508 invoked by uid 22791); 17 Nov 2006 06:17:28 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Nov 2006 06:17:20 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gkx2F-0004g4-R0 for gdb-patches@sources.redhat.com; Fri, 17 Nov 2006 07:17:11 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 07:17:11 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 07:17:11 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI: frozen variable objects Date: Fri, 17 Nov 2006 06:17:00 -0000 Message-ID: References: <200611161547.46997.vladimir@codesourcery.com> <1163690698.3219.199.camel@localhost.localdomain> <1163712982.5060.226.camel@funkylaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit User-Agent: KNode/0.10.2 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/msg00159.txt.bz2 Frédéric Riss wrote: > 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. 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 Those alternatives are roughly at the same scale of complexity. Since the printing code should look at the value to decide if it should print "" instead not-yet fetched value, it might as well avoid calling value_fetch_lazy. And doing (1) would mean that value_fetch_lazy no longer guarantees that the data is fully fetched, which will be confusing. - Volodya