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

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Jan 20, 2004 at 08:51:09AM +0200, Eli Zaretskii wrote:
> > 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?

By all means :)

> Daniel, do you object to having the feature you wanted in `x', rather
> than in `print'?  If you do, could you please explain why?

Because, at the moment, we have a common syntax shared by print and
examine - but some of the options don't make sense (I claim) for print. 
But they do all make sense for examine.  Witness:

(gdb) help x
Examine memory: x/FMT ADDRESS.

For a double located in memory, you can already do x/2x &double_var,
and I often do.  You can't apply & to a register; I suppose that would
be another reasonable alternative, but that changes the C expression
syntax instead of the syntax of a specific GDB command, and I don't
much fancy the idea.  You can't apply & to a constant, either.  I've
wanted to do p/x 2.0 and have some way to get the representation out
from that.  Right now the only way I know is:
(gdb) set *(double *)($sp - 1024) = 2.0
(gdb) x/2x $sp - 1024

Which I try to avoid doing, for obvious reasons.

> 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?

I don't think that it is a maintenance command - see my example about
p/s 0x62636566.  I also think that adding a new print format flag that
examines without changing the existing ones will be more confusing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer