From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12004 invoked by alias); 18 Jan 2008 01:35:18 -0000 Received: (qmail 11996 invoked by uid 22791); 18 Jan 2008 01:35:17 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jan 2008 01:34:46 +0000 Received: from kahikatea.snap.net.nz (152.60.255.123.dynamic.snap.net.nz [123.255.60.152]) by viper.snap.net.nz (Postfix) with ESMTP id C4A963D90D6; Fri, 18 Jan 2008 14:34:43 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 872558FC6D; Fri, 18 Jan 2008 14:34:40 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18320.559.863596.871051@kahikatea.snap.net.nz> Date: Fri, 18 Jan 2008 01:35:00 -0000 To: "Marc Khouzam" Cc: Subject: RE: -var-update using formatted value In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA04290E3C@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA04290E3C@ecamlmw720.eamcs.ericsson.se> X-Mailer: VM 7.19 under Emacs 23.0.50.32 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00159.txt.bz2 [aside - can you please fit your messages into 80 columns] > I guess the problem is that GDB makes the assumption that the front-end only cares about the > last value retrieved by evaluate-expression. Although this is sometimes the case, other times > it is not. Previously -var-evaluate-expression was needed because values weren't displayed when variable objects were created (-var-create now includes the value field, -var-list-children has the --all-values option). Given that -var-update provides a record of all changes, I'm not sure that -var-evaluate-expression is necessary now. > To solve this in GDB: > Since both use cases are valid (at least to me), the only way I can think to solve this is > to have an extra flag to var-update. Something like [--content-changed | --displayed-value-changed] > It would be a separate flag than the --no-values one. > The front-end could then decide which behavior it wants. > It's not pretty but that is all I got. > I know submitting a patch is the proper thing to do, but I didn't think this idea was going > to be accepted easily, so I'm suggesting it first. > > To solve this in the front-end: > I originally thought I could always use the natural format before doing a var-update, but it is not > that simple since I have to use the natural format for the root but also for all of the children > of that root. So my choices are: > 1- don't cache (this causes the most increase in front-end-to-GDB communication) Generally I don't think changing the format of already retrieved values is expensive. You said: GDB itself is running on a potentially slow processor, with a small bandwidth connection to the front-end. Could you expand on that scenario? > 2- when changing the format of a varObject and getting the value, immediately set it back to natural > (this will keep all varObjects, roots and children, at natural) > 3- before doing a -var-update on the root, set the root AND all its children to natural > 4- creating a variable object for each format. This turns out not to be efficient (if I understood > correctly) because each of the five varObjects will need to be var-updated and will need to go > read the raw value in memory, instead of doing this once. > > Solutions 2 or 3 are my best choices I believe. But it would be nice to have GDB support this. They're quite intrusive changes for what seems like a very specialised case. -- Nick http://www.inet.net.nz/~nickrob