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

Daniel Jacobowitz
2004-01-20T14:52:34Z

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