From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23547 invoked by alias); 20 Jan 2004 19:33:55 -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 23445 invoked from network); 20 Jan 2004 19:33:53 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Jan 2004 19:33:53 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Aj1dF-0006tW-HT; Tue, 20 Jan 2004 14:33:49 -0500 Date: Tue, 20 Jan 2004 19:33:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: cagney@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted Message-ID: <20040120193349.GA26311@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , cagney@gnu.org, gdb-patches@sources.redhat.com References: <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> <2427-Tue20Jan2004085108+0200-eliz@elta.co.il> <20040120145225.GA10459@nevyn.them.org> <2719-Tue20Jan2004211055+0200-eliz@elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2719-Tue20Jan2004211055+0200-eliz@elta.co.il> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00561.txt.bz2 On Tue, Jan 20, 2004 at 09:10:55PM +0200, Eli Zaretskii wrote: > > Date: Tue, 20 Jan 2004 09:52:25 -0500 > > From: Daniel Jacobowitz > > > > > Daniel, do you object to having the feature you wanted in `x', rather > > > than in `print'? If you do, could you please explain why? > > > > Because, at the moment, we have a common syntax shared by print and > > examine - but some of the options don't make sense (I claim) for print. > > But they do all make sense for examine. > > Sorry, I don't see how is this relevant. Suppose we add a new format > letter to `x', one that doesn't exist in `print'--would that be okay, > and if not, why not? > > > I don't think that it is a maintenance command > > We have wuite a few examples of obscure features that we pushed to > maint. I don't see why this one cannot. > > I do agree that it's better to have it on a regular command. > > > I also think that adding a new print format flag that examines > > without changing the existing ones will be more confusing. > > Please tell why. I don't see why it would be confusing to add a new > format that is defined to always show the memory representation of the > value in hex. I'll respond to these all together, since there's really the same answer to all of them: I think there is a general unimplemented feature here, not just the specific "show me the hex representation of this double". Examples I have in mind: - Displaying an integer to a sequence of characters p/s 0x6263 -> "ab" - Displaying a double-precision value in hex: p/x 2.0 -> 0x4000000000000000 - Displaying a double-precision value in binary: p/t 2.0 -> 01000000000000000000000000000000 00000000000000000000000000000000 - Displaying an integer (hex or otherwise) value as a double p/f 0x4000000000000000LL -> 2.0 - Displaying an integer (hex or otherwise) value as a long double - this one is trickier, since we don't normally have an integer type that is big enough, but if we did: p/gf 0x400000000000000000000000LLL -> 2.0 I didn't pick these examples at random. I've wanted to do every single one of these in the past three months, for values in registers rather than typed-in constants. I had to store them to the inferior's memory to do it. And then x/2x gives you the two words broken up, and you get: 0x00000000 0x40000000 when perhaps you wanted: 0x40000000_00000000 They both indicate that on a little endian system the set bit is in the most-significant, therefore highest-byte-addressed, byte. I think that adding a flag to show the representation in hex would be intuitive, but not general enough, and that extending the existing /x to do the same thing would be more natural. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer