From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14899 invoked by alias); 20 Jan 2004 21:29: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 14888 invoked from network); 20 Jan 2004 21:29:23 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 20 Jan 2004 21:29:23 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 26B432B8F; Tue, 20 Jan 2004 16:29:20 -0500 (EST) Message-ID: <400D9DAF.3020506@gnu.org> Date: Tue, 20 Jan 2004 21:29:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00565.txt.bz2 > > 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. Apparent lack of value is not a bug. Often its a sign of well thought out design. Consider: struct st { int i:12; j:4; short s } stv = { 1, 2, 3 }; (something that is currently causing the linux kernel grief - GCC 3.4 finally rejects typeof stv.i). For: (gdb) print stv { 1, 2, 3} (gdb) print/f stv { 1.0, 2.0, 3.0 } GDB interprets stv.i and stv.j as _abstract_ values and then formats and displays them accordingly. At the same time for: (gdb) x/b &stv 0x1234000: 0x00120003 GDB displays the bits used in the underlying representation of stv. The thing that is missing here, and I suspect at the time this code was written was never thought to be a problem so ignored, is a mechanism for examining / manipulating the underlying representation of a value that is not sequentially laid out in memory. For instance: (gdb) ptype v vector int i[4] (gdb) print &v[1] - &v[0] 1 should always work (that's valid C), only it doesn't when the value isn't in memory: (gdb) print &$mm0.v8_int8[1] - &$mm0.v8_int8[0] Attempt to take address of value not located in memory. Similarly, it should be possible to interpret the underlying representation of an arbitrary value vis (Eli, yes, /v doesn't exist): (gdb) x/8c &$mm0 (gdb) x/f &$mm0.v2_int32[1] or with a new /v[alue] option (for want of a better letter): (gdb) x/8vc $mm0 but I suspect that getting & working, while harder, would be better. Andrew > 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. >