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

[Daniel Jacobowitz <drow@mvista.com>]

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" 
> >>command.
> >
> >
> >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
the manual.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer