From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5041 invoked by alias); 19 Feb 2004 22:53:32 -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 4468 invoked from network); 19 Feb 2004 22:44:48 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 19 Feb 2004 22:44:48 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 6EF5A80001E; Thu, 19 Feb 2004 17:44:47 -0500 (EST) Message-ID: <40353C5F.2060909@redhat.com> Date: Thu, 19 Feb 2004 22:53:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Andrew Cagney Cc: Daniel Jacobowitz , 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> <400D9DAF.3020506@gnu.org> In-Reply-To: <400D9DAF.3020506@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00545.txt.bz2 Just to inform that the original patch has been checked in. -- Jeff J. Andrew Cagney wrote: >> >> 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. >> > > >