This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]