From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22664 invoked by alias); 20 Jan 2004 06:55:25 -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 22654 invoked from network); 20 Jan 2004 06:55:24 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sources.redhat.com with SMTP; 20 Jan 2004 06:55:24 -0000 Received: from zaretski ([80.230.153.224]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DJI40866; Tue, 20 Jan 2004 08:54:46 +0200 (IST) Date: Tue, 20 Jan 2004 06:55:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-Id: <2427-Tue20Jan2004085108+0200-eliz@elta.co.il> CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <20040120054836.GA23548@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 20 Jan 2004 00:48:36 -0500) Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted Reply-to: Eli Zaretskii 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> <20040120054836.GA23548@nevyn.them.org> X-SW-Source: 2004-01/txt/msg00550.txt.bz2 > Date: Tue, 20 Jan 2004 00:48:36 -0500 > From: Daniel Jacobowitz > > 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. May I wave the truce flag here? Daniel, do you object to having the feature you wanted in `x', rather than in `print'? If you do, could you please explain why? If having this on `x' is not something we agree to, how about a `maint' command, or a new format letter for `print' that would specifically be designed to reveal the bit pattern of the value as it would be stored in memory?