From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18700 invoked by alias); 12 Jan 2008 03:41:46 -0000 Received: (qmail 18688 invoked by uid 22791); 12 Jan 2008 03:41:45 -0000 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 12 Jan 2008 03:41:22 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m0C3fLDQ027698 for ; Fri, 11 Jan 2008 21:41:21 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 21:41:20 -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: Sat, 12 Jan 2008 03:41:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA2DE08B@ecamlmw720.eamcs.ericsson.se> 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> From: "Marc Khouzam" To: 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/msg00082.txt.bz2 > My logic for making the change was that changes in string values were only > detected if their first character changed. For example the change > "GNU" to GDB": > strcpy (fred, "GNU"); > strcpy (fred, "GDB"); > > $4 =3D 0x804a018 "GNU" > $5 =3D 0x804a018 "GDB" Good point. I wouldn't have thought of that. > In Eclipse how does the user know if he is looking at a binary or decimal= value? In the CDT, they use 0b as a prefix (e.g., 0b1101). And as Daniel mentions: "it would be nice to be able to type binary number= s in GDB." Currently (to my knowledge) there is no way to assign a binary value to a v= ariable object. It would be nice to be able to do -var-assign var1 0b1011 So I like the idea of GDB supporting the 0b prefix. Independently of that though, after thinking about the problem some more, I= believe there are other issues with the current comparison for var-update. For example, in your example of strings changing from=20 natural value: 0x804a018 "GNU" to natural value: 0x804a018 "GDB" If the variable object tracking this has its format set to anything else th= an 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. Another example is the case of a double changing from value 1.1 to 1.2 If the variable object tracking this has its format set to anything else th= an natural, both 1.1 and 1.2 values are truncated to 1 or 0x1 etc, and -var-update will= again miss the change in value. So I'm thinking that it is a good idea to use the printed value to do the c= omparison for var-update, but that it should always use the natural format to do this. My concern was if there is a type that would have the same value in natural= format map to two different values for some other format. I was originally worried about= boolean, which could show 'true' for anything different than 0, but I noticed that G= DB will always show 1 or 0x1 etc for a boolean that is anything but 0; so I think t= his is also OK. But of course, there may be other details I am not aware of. Always using the natural format to do the var-update comparison would also prevent -var-update from showing a change after the use of -var-set-format when the program did not actually advance, and the variable did not actuall= y change. Marc