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

[Andrew Cagney <cagney@gnu.org>]

> 
> 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.
>