From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25518 invoked by alias); 15 Jan 2008 18:43:57 -0000 Received: (qmail 25508 invoked by uid 22791); 15 Jan 2008 18:43:56 -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; Tue, 15 Jan 2008 18:43:29 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JEqku-0001w3-Hn for gdb@sources.redhat.com; Tue, 15 Jan 2008 18:43:24 +0000 Received: from uslec-66-255-52-67.cust.uslec.net ([66.255.52.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 18:43:24 +0000 Received: from ghost by uslec-66-255-52-67.cust.uslec.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 18:43:24 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: RE: -var-update using formatted value Date: Tue, 15 Jan 2008 18:43:00 -0000 Message-ID: References: <6D19CA8D71C89C43A057926FE0D4ADAA04290E1B@ecamlmw720.eamcs.ericsson.se> <18311.60638.724524.220449@kahikatea.snap.net.nz> <20080111225928.GA26360@caradoc.them.org> <18311.65093.38930.103045@kahikatea.snap.net.nz> <20080111235219.GA29698@caradoc.them.org> <6D19CA8D71C89C43A057926FE0D4ADAA2DE08B@ecamlmw720.eamcs.ericsson.se> <20080112034900.GA8947@caradoc.them.org> <6D19CA8D71C89C43A057926FE0D4ADAA2DE08C@ecamlmw720.eamcs.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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/msg00112.txt.bz2 Marc Khouzam wrote: > >> > For example, in your example of strings changing from >> > natural value: 0x804a018 "GNU" to >> > natural value: 0x804a018 "GDB" >> > If the variable object tracking this has its format set to anything >> > else than natural, the actual string is not printed and the value seems >> > to stay the same so -var-update will not detect the change in value. >> >> That is deliberate. I reread your message, and I still can't see a >> good reason for -var-update to report a changed variable if >> -var-evaluate-expression is going to continue to display it the same >> way, i.e. as if no update has occurred. If you're worried about >> multiple formats, maybe you should keep a varobj for each instead of >> switching one around? > > I had assumed var-update to be an indication of when the actual content of > a variable > has changed. Although, truth be told, the documentation is clear that > var-update will trigger only if -var-evaluate-expression changed (for the > current format.) And I do see your point for this logic. > > You are right that my issue is with multiple formats and your suggestions > of different variable objects would work fine. > However, in my case, where we work with embedded systems and we want to > minimize the requests to the (potentially very slow) back-end, I was > hoping to share the same variable > object and to cache the value of each format. I don't understand the above. Changing format of a variable object is not supposed to refetch if from the target, so caching string representation on frontend side is not necessary. > This use-case requires a > var-update that will indicate if a value has changed in any format, not > just the current one, so as to know to invalidate the cache. > But I believe I can achieve this by setting the format to natural before > every -var-update, which I have to do anyway until the -var-update fix for > binary numbers and floats (please see other bug description below) is > available. > > For the sake of completeness, let me just point out that the current > var-update implementation > can often show a change when var-evaluate-expression still displays the > same thing. This is because the stored 'print_value' is not updated with > each -var-evaluate-expression request e.g., > int z = 0xb; > > -var-create - * z (print value is remembered to be 11) > -var-set-format var1 hex > -var-evaluate-expression var1 => Oxb > -exec-step > -var-update var1 => will show var1 to have changed As I've said before, it's a bug -- -var-set-format should recompute the stored value. In fact, whereas a variable object hold the formatted string, that string appears to be not used when reporting variable value. -var-evaluate-expression goes to c_value_of_variable eventually, and that uses value_get_print_value. I think we need to: 1. Make -var-evaluate-expression directly return stored printed value 2. Make -var-set-format recompute the stored printed value. Comments? - Volodya