From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7407 invoked by alias); 18 Jan 2008 19:26:00 -0000 Received: (qmail 7397 invoked by uid 22791); 18 Jan 2008 19:25:59 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jan 2008 19:25:36 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m0IJPYu8011327 for ; Fri, 18 Jan 2008 13:25:34 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 13:25:34 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: -var-update using formatted value Date: Fri, 18 Jan 2008 19:26:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA2DE099@ecamlmw720.eamcs.ericsson.se> References: <18320.559.863596.871051@kahikatea.snap.net.nz> <6D19CA8D71C89C43A057926FE0D4ADAA2DE096@ecamlmw720.eamcs.ericsson.se> <20080118154059.GA22643@caradoc.them.org> <6D19CA8D71C89C43A057926FE0D4ADAA2DE097@ecamlmw720.eamcs.ericsson.se> <20080118175312.GA29504@caradoc.them.org> From: "Marc Khouzam" Cc: 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/msg00177.txt.bz2 > > In my case, since I display all formats (sometimes), I need to do=20 > > var-evaluate-expression on every displayed variable, since var-update w= on't=20 > > properly tell me which variable really changed (in the case of float an= d strings). > > We should fix that. Is checking in natural format the answer? Do we > really need to check all supported formats - that could get out of > hand if we support custom formatting someday. I didn't find an example where checking the natural format would not work. But that may not mean much :-) Boolean could have been a problem (0x1, 0x2, 0x3 etc are all "true" in natu= ral), but it seems that for now, GDB always shows 0x1 for true. A safer way may be to have GDB check for content difference, as it used to = do before. But it would also need to check the natural printed format for str= ings (to detect a change from "GDB" to "GNU"). Marc