From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29954 invoked by alias); 20 Jan 2004 05:48:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29894 invoked from network); 20 Jan 2004 05:48:37 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Jan 2004 05:48:37 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Aioke-0006YB-No; Tue, 20 Jan 2004 00:48:36 -0500 Date: Tue, 20 Jan 2004 05:48:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted Message-ID: <20040120054836.GA23548@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3FDA26B1.6010704@redhat.com> <1031212221704.ZM22539@localhost.localdomain> <3FDA636F.30204@redhat.com> <400C58E6.4070908@redhat.com> <400C60C0.9040702@gnu.org> <20040119231853.GA6132@nevyn.them.org> <400C7948.9060300@gnu.org> <20040120012252.GA4828@nevyn.them.org> <400C8CC0.3040706@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <400C8CC0.3040706@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00547.txt.bz2 On Mon, Jan 19, 2004 at 09:04:48PM -0500, Andrew Cagney wrote: > >(gdb) print/x doublevar > >>>$1 = 0xc000000000000000 > >>>(gdb) print/i doublevar > >>>???? [no preference really] > > > >> > >>No. That would be wrong. print/ prints the value (not the > >>implementation) using the specified format. Being able to examine the > >>underlying implementation in various formats is more of an "examine" > >>command. > > > > > >Andrew, please explain to us all how you can respond to "I think this > >would be a better, different-than-the-current behavior" with "No, that > >would be wrong". > > "us all"? Yes, since "That would be wrong" is a pretty sweeping policy statement for GDB. It indicates the existance of an absolute standard that we need to adhere to. If there is one, I've missed it, please add it to the manual. > "print" displays the value, not the underlying representation, using > normal language rules. Consider: > int i = 1.0; > extern foo (int i); > foo (1.0: > which don't leave something like 0xc0000000 in i. On the other hand So if you use no format characters, you'll get the expected result. I think at least one word is missing from the above example... > "examine" lets you display the underlying [memory] representation in > various forms. > > The problem here is not print/f, but rather that there isn't way to > examine the underlying representation of non-memory values (most often > registers) this leaves people attempting: > x/x $fp0 > and then: > p/x $fp0 > :-( My point is that we can _change_ the behavior of print. I think that it is reasonable for the process to be something like this: print /format expression Evaluate expression Expression has a type Examine the value of that type according to /format [interpret its bits as a double, or as hex, or whatever...] This isn't the first time this has come up, Jim (?) made a similar suggestion some time ago for the case of ObjC. I think that I disagreed with it at the time, but I've got a history of being inconsistent. Think about it. What use do these have: p/f int_var p/x double_var None that I can see. p (double) int_var is obviously .0 in C, and p/x (int) double_var is obviously 0x, but the format specifiers don't add value. Here's some value they could add. Now, for ints vs. pointers it may be a little messier. This might even let me solve a long-standing complaint. Given $r1 = 0x62636566, I'd love to have a way to make gdb print "bcef". Or "fceb" or whatever else. p/s $r1? p/x 0x62636566? Examine does an implicit dereference and print doesn't, so this seems like a logical use of printf. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer