Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

[Jeff Johnston <jjohnstn@redhat.com>]

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 <int_var>.0 in C,
>> and p/x (int) double_var is obviously 0x<truncate(double_var)>, 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.
>>
> 
> 
>