From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23316 invoked by alias); 16 Nov 2006 16:26:07 -0000 Received: (qmail 23307 invoked by uid 22791); 16 Nov 2006 16:26:06 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-02.spheriq.net (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Nov 2006 16:25:51 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-02.spheriq.net with ESMTP id kAGGPckb018120 for ; Thu, 16 Nov 2006 16:25:38 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-01.spheriq.net with ESMTP id kAGGPahb026067 for ; Thu, 16 Nov 2006 16:25:37 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id kAGGPYi3019619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 16 Nov 2006 16:25:36 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 28134DA52; Thu, 16 Nov 2006 16:25:25 +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 E93FD473EE; Thu, 16 Nov 2006 16:25:22 +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 CIZ11315 (AUTH "frederic riss"); Thu, 16 Nov 2006 17:25:20 +0100 (CET) Subject: Re: MI: frozen variable objects From: Frederic RISS To: Daniel Jacobowitz Cc: Greg Watson , Vladimir Prus , gdb-patches@sources.redhat.com In-Reply-To: <20061116155504.GA11539@nevyn.them.org> References: <200611161547.46997.vladimir@codesourcery.com> <1163690698.3219.199.camel@localhost.localdomain> <20061116155504.GA11539@nevyn.them.org> Content-Type: text/plain Date: Thu, 16 Nov 2006 16:26:00 -0000 Message-Id: <1163694319.3219.216.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/msg00142.txt.bz2 On Thu, 2006-11-16 at 10:55 -0500, Daniel Jacobowitz wrote: > Why should the GUI have a separate data structure for the value in a > manipulatable form? I suspect that some GUIs only keep it around as a > string, for display. Then if the user wants a radix switch, the > easiest way is to tell GDB (-var-set-format). [Not directly related to the varobj-freezing topic: I think that GUIs had a better time doing exactly what you say rather than doing it in a "I know better than the debugger"-way. I've already been quite irritated with Eclipse doing endianness swapping by itself in its memory view.] > > 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. > > Exactly. My original sketch for this stuff had an XML file that we > passed from the target directly to the GUI, but that duplicates a > certain amount of work between GDB and the GUI, and between GUIs. > > > I agree with your general point though. Maybe the functionality > > shouldn't be in the debugger, but the information should be available to > > the GUI... through varobj properties maybe? Of course this means that > > the GUIs have to known about and respect this information. > > And what about people who actually use the command line GDB? That was > the argument that tipped the scales for me in favor of this approach. > It allows the varobj mechanism to be consistent with what we want the > GDB CLI to offer to the user. Of course things should be consistent between frontends... but I think that could be argument _against_ the varobj-freezing. If we take a look at your example: > struct regs > { > int InterruptStatus; > int Config; > int ClockVal; > } *regs; > > Maybe Config is a static register, ClockVal is a continually updating > read-only timer, and InterruptStatus is a read-sensitive value where > reading acknowledges any reported interrupt (this is not uncommon). If > the user does "print/x *regs", and GDB can determine that yes, regs is > really pointing to some hardware registers that GDB knows about, it > would be awesome for GDB to say: > > $1 = { InterruptStatus = , Config = 0x8000, > ClockVal = 0x1212 } The CLI doesn't use varobjs to display values. Vladimir's change wouldn't directly help here. Maybe the framework for doing exactly that should land first and then the UI. I suspect that if CLI is modified to generate an output like you describe, MI would get something similar as a side-effect, wouldn't it? Fred.