This is the mail archive of the
mailing list for the GDB project.
Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted
On Mon, Jan 19, 2004 at 09:04:48PM -0500, Andrew Cagney wrote:
> >(gdb) print/x doublevar
> >>>$1 = 0xc000000000000000
> >>>(gdb) print/i doublevar
> >>>???? [no preference really]
> >>No. That would be wrong. print/<format> prints the value (not the
> >>implementation) using the specified format. Being able to examine the
> >>underlying implementation in various formats is more of an "examine"
> >Andrew, please explain to us all how you can respond to "I think this
> >would be a better, different-than-the-current behavior" with "No, that
> >would be wrong".
> "us all"?
Yes, since "That would be wrong" is a pretty sweeping policy statement
for GDB. It indicates the existance of an absolute standard that we
need to adhere to. If there is one, I've missed it, please add it to
> "print" displays the value, not the underlying representation, using
> normal language rules. Consider:
> int i = 1.0;
> extern foo (int i);
> foo (1.0:
> which don't leave something like 0xc0000000 in i. On the other hand
So if you use no format characters, you'll get the expected result. I
think at least one word is missing from the above example...
> "examine" lets you display the underlying [memory] representation in
> various forms.
> The problem here is not print/f, but rather that there isn't way to
> examine the underlying representation of non-memory values (most often
> registers) this leaves people attempting:
> x/x $fp0
> and then:
> p/x $fp0
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
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
Think about it. What use do these have:
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. 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
MontaVista Software Debian GNU/Linux Developer