From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31491 invoked by alias); 20 Jan 2004 14:52:34 -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 31410 invoked from network); 20 Jan 2004 14:52:30 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Jan 2004 14:52:30 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AixEw-0005Ay-0y; Tue, 20 Jan 2004 09:52:26 -0500 Date: Tue, 20 Jan 2004 14:52: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: <20040120145225.GA10459@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , cagney@gnu.org, gdb-patches@sources.redhat.com References: <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> <2427-Tue20Jan2004085108+0200-eliz@elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2427-Tue20Jan2004085108+0200-eliz@elta.co.il> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00555.txt.bz2 On Tue, Jan 20, 2004 at 08:51:09AM +0200, Eli Zaretskii wrote: > > 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? By all means :) > 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. Witness: (gdb) help x Examine memory: x/FMT ADDRESS. For a double located in memory, you can already do x/2x &double_var, and I often do. You can't apply & to a register; I suppose that would be another reasonable alternative, but that changes the C expression syntax instead of the syntax of a specific GDB command, and I don't much fancy the idea. You can't apply & to a constant, either. I've wanted to do p/x 2.0 and have some way to get the representation out from that. Right now the only way I know is: (gdb) set *(double *)($sp - 1024) = 2.0 (gdb) x/2x $sp - 1024 Which I try to avoid doing, for obvious reasons. > 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? I don't think that it is a maintenance command - see my example about p/s 0x62636566. I also think that adding a new print format flag that examines without changing the existing ones will be more confusing. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer