This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted
> Date: Tue, 20 Jan 2004 00:48:36 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
>
> 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.
May I wave the truce flag here?
Daniel, do you object to having the feature you wanted in `x', rather
than in `print'? If you do, could you please explain why?
If having this on `x' is not something we agree to, how about a
`maint' command, or a new format letter for `print' that would
specifically be designed to reveal the bit pattern of the value as it
would be stored in memory?