[RFC]: remove inconsistency in printcmd.c: print_scalar_formatted
Jeff Johnston
jjohnstn@redhat.com
Thu Feb 19 22:53:00 GMT 2004
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.
>>
>
>
>
More information about the Gdb-patches
mailing list