From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12511 invoked by alias); 16 Nov 2006 15:25:29 -0000 Received: (qmail 12497 invoked by uid 22791); 16 Nov 2006 15:25:28 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-04.spheriq.net (HELO lon-del-04.spheriq.net) (195.46.50.101) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Nov 2006 15:25:18 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-04.spheriq.net with ESMTP id kAGFPEmJ024898 for ; Thu, 16 Nov 2006 15:25:14 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-03.spheriq.net with ESMTP id kAGFPBJm008584 for ; Thu, 16 Nov 2006 15:25:13 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 kAGFPAgr023759 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 16 Nov 2006 15:25:11 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 3C978DA42; Thu, 16 Nov 2006 15:25:01 +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 5B65B473E4; Thu, 16 Nov 2006 15:25:00 +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 CIZ09279 (AUTH "frederic riss"); Thu, 16 Nov 2006 16:24:58 +0100 (CET) Subject: Re: MI: frozen variable objects From: Frederic RISS To: Greg Watson Cc: Vladimir Prus , gdb-patches@sources.redhat.com In-Reply-To: References: <200611161547.46997.vladimir@codesourcery.com> Content-Type: text/plain Date: Thu, 16 Nov 2006 15:25:00 -0000 Message-Id: <1163690698.3219.199.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/msg00139.txt.bz2 On Thu, 2006-11-16 at 06:58 -0700, Greg Watson wrote: > I don't really understand the motivation for putting this kind of > functionality into gdb. Any GUI that is more than just a front-end > for gdb will most likely have an internal data structure representing > the value of the variable, and can retain or manage access to the > value if required. It seems to me that adding functionality like this > to gdb just adds to bloat when it is really a GUI function anyway. 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. 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. Fred.