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

Andrew Cagney
2004-01-20T21:29:25Z

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